draft document : Good Security Practice for a Free Software release
Posted 14 Nov 2002 at 17:48 UTC by adulau
As everybody knows, a lot of trojaned Free Software has been found. A vast majority of them are not using OpenPGP signed checksum file. I'm currently trying to make a basic HOWTO to make a Free Software release including OpenPGP signature. This can minimize the risk (as long as the user is checking the signature ;-). Here is a draft in PS and PDF format.
Don't hesitate to provide comments and feedback following your own experience of the issue. (I hope to include the chapter in the Software Release HOWTO afterwards)
If you only provide PS or PDF, anyone trying to give detailed on your document will have to type portions in by hand. PS and PDF are only suited to the final versions of your document.
In any case, there is very little content: publish MD5 checksums, use digital signatures. It focuses one only one problem: trojans. It doesn't address practices that lead to security holes in the first place.
For example, here's a snippet of the intro. "As you should already know, there is an excellent HOWTO1".
I'm just want to focus on software release to make a simple chapter for the Software Release HOWTO. (It's not about Secure Programming or Secure Software Engineering)
The feedback needed is just about the current practice of free software developer for their software release to get a global overview.
There is not so much developers using digital signatures. So it's just the purpose of the chapter... to increase the use of digital signatures for Free Software project and limit the risk of corrupted distribution.
PS : a LyX format is also available.
Security is mostly a social problem (who do you trust? who has write access? who reads patches?), not a technical one (md5sums, etc.)
So, here's a question for you to answer: "how should peer-review in the free software community prevent trojans?"
- should everyone who's interested in a project run diff -ru
between versions, and skim-read? Would this help? Is it easy to
hide trojans? (I imagine inserting buffer-overflows might be
- is this mainly a "maintainer's" responsibility, or is it just like dealing with any-old bug? (many-eyes, all bugs are shallow, etc.)
- should SCM tools do mirroring, etc. and detect when something's
amiss? Is this doable?
Simplify, posted 18 Nov 2002 at 13:49 UTC by gerv »
You say about MD5:
"This is not enough to guarantee the integrity of your software packages."
Then why bother publicising MD5sums at all? That's like saying "This crypto algorithm makes your data completely secure 90% of the time." If you have a better method (GPG signing) then why ask people to check unsigned MD5s?
You then offer two possibilities for GPG signing - clear-signing and detached signing. Which is better? Why? Or is it a trade-off of some sort?
We need two things:
1) A command a person can run to sign a file, and produce a file containing that signature. Under the covers, it may well produce an MD5sum and sign that. Fine, whatever - the developer shouldn't care. They just run the command, type in their passphrase, and upload both files to the server. The sig file should have a filename relationship to the original - appending ".sig" seems to be fairly standard. (Ideally, the signature should be in the same file - do .gz files have a Comment field?)
2) A command a user can run to verify you produced the software. They would run the command, optionally giving it the relevant public key, and it would spit out "This software was signed by The FooBar team" (perhaps with a metric of how good the chain of trust is - "with 90% probability").
3) Both commands (shell scripts) should ship with as many distributions as you can persuade to include them, and/or you should make them available for download.
If you start with LaTeX, you could try feeding it to a program called latex2html to generate different kinds of html versions of the page for online viewing and especially linking into.