Item1317: Release tarball and all downloadable material should be somehow certified

Babar recently pointed out in email:

> Just to mention that many many projects provide MD5 or SHA signatures on
> the very same server where you can download the release.
> This adds nothing security-wise, so please publish the tar.gz on
> sourceforge, and the checksum files some other place (on the wiki,
> in a restricted editing page maybe).

We upload md5 files for extensions from perl build.pl upload to the same place as the archives.

We need a better strategy.....

-- CrawfordCurrie - 18 Mar 2009

Sorry, what I wanted to point out in fact was the weakness of MD5 security-wise. As Sven pointed out, putting the MD5 on a remote server is just an added layer of pseudo-security which can also be faked (as one can tweak the package so that it matches an MD5 checksum).

Anyway, I think this bug item is a great opportunity to re-think our strategy regarding upload, signature and packaging.

Therefore, I've changed this bug item summary from "MD5's provided on same server as packages".

-- OlivierRaginel - 18 Mar 2009

Agreed. I like the idea of GPG signing packages, I'm just mildly concerned that it may be a barrier for people using them. Of course, with good automation it should be no problem, but you never can tell...

-- CrawfordCurrie - 18 Mar 2009

Just want to point out that for MacOS I attached the installer packages directly to FoswikiOnMacOSXLeopard. This is definitely a security hole as anybody can attach a bogus/malicious installer package. We definitely need a controlled publishing and download area combined with the proper hashing/signature mechanism.

-- MatthiasWientapper - 19 Mar 2009

Update: Have added GPG signature to MacOS package.

-- MatthiasWientapper - 20 Mar 2009

For the extensions the requirement must for sure be

• Signing extensions must be a volunteer thing.
  • The author decides if he wants to sign his extension
  • The downloader decides if he wants to download unsigned packages. So far very few people have shown concern probably because there are so many eyes on anything uploaded incl many people that looks quickly at the code. It is difficult to upload something evil without getting detected.
• The signature should be generated by build contrib when you upload - enabled by some switch. besides this you need to have a GPG keypair and gnupg.
• The signature is the default format - same name as the file it signs appended .asc
• The configure interface can later be extended to show an icon or simiar for extensions that are signed
• The configure script can later check the integrity using the key and signature file
• The community need to make a list of "good guys" that are generally trusted. Criteria to get on the list should be same as getting SVN access.

This MUST be a volunteer thing. The last thing we want is to let FUD and red tape and knowledge barrier (GPG has a learning curve) be a barrier that discourage contributions. In all the history of TWiki and now Foswiki we have been able to protect against evil scripts through the constant monitoring of contributions. And additionally when an extension is uploaded I can see who did it and I have a pretty good idea who I can trust and who I need to keep an extra eye on.

There is always a balance between the benefits of security and the loss it gives to deny access or add barriers. Maximum possible security is not always the level that gives best payback. The whole wiki idea builds on this soft security principle where you combine the full audit trail with the many eyes that watch. And it has proven to work better and safer than anything closed I have seen.

-- KennethLavrsen - 20 Mar 2009