Revision as of 16:46, 2 September 2015

Feedback and bug reports about this site go here.

Click the "start a new topic" tab above or click "edit this section" next to an existing topic.

Feedback

What is this section for?

This section is for feedback about how this beta website is working. Admin (talk) 12:27, 23 December 2013 (EST)

Bug reports

What's a bug and what's not?

Just report it and we'll figure it out. Admin (talk) 12:29, 23 December 2013 (EST)

OpenSSL Heartbleed bug

On April 7, 2014, it was announced that a bug in the TSL Heartbeat extension of OpenSSL allows for a major exploit which could let an attacker read up to 64KB of server memory used by that process. This exploit left encrypted communications, including cookies and passwords sent to this site, potentially vulnerable to viewing by an attacker. This is a major bug that effects a large portion of websites on the internet. We will be researching this issue in the days to come and provide additional information. Admin (talk) 03:14, 9 April 2014 (EDT)

It has been comfirmed by multiple third-party sources that the private keys of server certificates are vulnerable to disclosure to an attacker by exploiting the Heartbleed bug, as well as the vulnerable information mentioned above. See http://www.engadget.com/2014/04/11/heartbleed-openssl-cloudflare-challenge/ for details) Therefore, although we not aware of any evidence that our private keys had been compromised, it should be assumed that any SSL communication to this site was not secure.

The reason that the software allowed an attacher to read up to 64KB of server memory is because the code that handled the TLS Heartbeat function did not do input sanitization of external input, specifically the length of the Heartbeat packet sent to the server from the client. The code just assumed that the client would provide honest information about what it was sending. An attacher simply sends a small (1-byte) packet and tells the sevrer, "Hi, I'm sending you 64KB, please send it back." Then the server sends 64KB of memory, which can contain clear data from the private SSL communications of other users.

Because input sanitization is such a basic necessity for clean and secure code, it's puzzling how a bug of this nature found its way into software whose purpose is to provide secure communications. We have heard no explanation from the developers of OPENSSL, and lacking any reason to continue to trust the software, we are exploring alternatives to OPENSSL. In the meantime, we will contine to leave SSL disabled on the site. (see the discussion, #SSL disabled on the site, below) - Admin (talk) 20:38, 14 April 2014 (EDT)

SSL disabled on the site

We have intentionally disabled SSL (https) communications on this site because of the Heartbleed bug. Users will not be able to use SSL (https) protocol to communicate with the site, which means that all information sent to or from the site will be in the clear (readable by anyone with access to the datastream). Since nearly everything sent to this site is publicly viewable anyway, it won't effect much. The only information which is not normally made public is your email address, password, IP address, cookies and other session/protocol data. Email addresses and IP's are generally sent in the clear anyway, so there is no additional exposure there. The cookies and session data are either normally sent in the clear or don't contain personal information, however, passwords are normally sent in an encrypted form to this site. So beginning 4/5/2014 until further notice, when you log on to the site, be aware that your password will be more susceptible to eavesdropping. Admin (talk) 03:22, 9 April 2014 (EDT)

Did a quick survey of wiki sites and found that only 25% implement CA'ed SSL (didn't check them for Heartbleed). Because of the nature of open wiki's, i.e., all the information is open, most of them don't enable SSL, even some high-traffic sites. For now, we are going to continue to leave SSL disabled and continue to research alternatives to OPENSSL. If anyone has concerns about it or wants to comment about the issue, please feel free to chime in. - Admin (talk) 21:10, 14 April 2014 (EDT)

Based on other exploits involving SSL that have surfaced since Heartbleed (such as LogJam), this seems like it was a good call. Ronald Smith (talk) 10:03, 24 May 2015 (EDT)

Bots

Since June 18, 2014, a bot has been automatically editing the page Main page/Historic events. Each day, it randomly selects an event on that page for inclusion on the Main Page. The bot runs under the name Historybuff. Details of its operation are on that user page. Admin (talk) 17:29, 15 July 2014 (EDT)

Test accounts

Several test accounts have been set up on the site. They are easily identified with usernames that contain "testuser" or something similar, or with real names that have all caps for the last name. Many are used to test and monitor the account creation facility on the site, but some are also used for test edits (which are generally identified in the edit summaries, but not always). So far, the account creation mechanism, which has been modified from the stock code from Mediawiki, seems to be operating nominally. Admin (talk) 17:29, 15 July 2014 (EDT)

Test accounts continue to be created on a regual basis in order to monitor database functionality and test the account-creation code. Admin (talk) 15:56, 4 August 2015 (EDT)

Shell shock bug

We shut down the web interface for several hours on Sept. 26, 2014 to address the Shell shock bug (aka. the Bash bug) see press write-up. As far as we can tell, no personal information was compromised using the exploit. Admin (talk) 23:56, 26 September 2014 (EDT)

If you have a wiki or any other server and need more info on the bug, see wikipedia's page on it here. Admin (talk) 23:56, 26 September 2014 (EDT)

Site outages

• The site was offline between the morning of 2014/12/08 and approximately midday 2014/12/09. Sorry for the inconvenience. Admin (talk) 02:51, 9 December 2014 (EST)

• Access to the site has been off and on for the past week, mostly off. Editing and account creation was prevented during outages. If you experience further issues, please contact us using the contact information at Meta:Egalib, Inc.. Thank you. Admin (talk) 11:01, 20 January 2015 (EST)

• The database was intentionally locked between late July 31, 2015 to mid August 4, 2015 in order to facilitate syncronization of the database between multiple systems which did not have connectivity during that time. This prevented write access to the DB (preventing editing and account creation on the main internet-connected system) during that period. There were also a few hours of complete site unavailability. Admin (talk) 15:56, 4 August 2015 (EDT)

• The site was unavailable between about 11:30 a.m. and 4:00 p.m. EDT on Sept. 2, 2015. Admin (talk) 16:46, 2 September 2015 (EDT)

The time is about an hour off, why?

This site always uses Eastern Standard Time even during Daylight Saving Time, so if you are at a location that observes DST it will appear to be off during DST. Admin (talk) 06:09, 16 May 2015 (EDT)

This is too confusing, so I changed the server to comply with DST and use a standard reference for updating the time periodically. Also, there were more issues with the system time than just the DST issue. Ronald Smith (talk) 10:04, 24 May 2015 (EDT)

The LocalSettings for Mediawiki had been changed to use a fixed offset for timecorrection which could cause issues for users who used the default timecorrection. I changed it so the default timecorrection is a tz database zone (America/New York) so the logs will display correct times for those users who use the default preference setting for timecorrection (even during Daylight Saving Time). Admin (talk) 01:36, 28 August 2015 (EDT)