draft document : Good Security Practice for a Free Software release

Posted 14 Nov 2002 at 17:48 UTC by adulau Share This

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)

not a good way to get feedback, posted 14 Nov 2002 at 19:20 UTC by jbuck » (Master)

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.

You can cut and paste PDF..., posted 14 Nov 2002 at 22:02 UTC by AlanShutko » (Journeyer)

For example, here's a snippet of the intro. "As you should already know, there is an excellent HOWTO1".

Only focusing on the release process of Free Software, posted 14 Nov 2002 at 22:18 UTC by adulau » (Journeyer)

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, posted 15 Nov 2002 at 20:29 UTC by clausen » (Master)

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?"

Some thoughts:

  • 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 doable...)

  • 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 » (Master)

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.


Still a bit more about the format, posted 13 Jan 2003 at 11:30 UTC by realblades » (Journeyer)

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.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page