Re: [Debconf-discuss] list of valid documents for KSPs
On Sun, May 28, 2006 at 09:22:10PM -0700, Thomas Bushnell BSG wrote: > Manoj Srivastava <[EMAIL PROTECTED]> writes: > > > Once he has broken faith, nothing coming from that source can > > be accepted, since the source is now tainted. Any information flow > > with that origination is tainted, and since you offer the same > > statements, without any form of untainting that is visible, I think > > you are rapidly approaching the untrusted relay category. > > What I don't see is what exactly the scam *was*. > > It seems to me that you are saying that presenting an ID which should > *scream* to anyone paying the least attention "this is not a > government ID", has, ipso facto, lied. > > But no, they haven't. They haven't forged, or been dishonest. In fact (as I understand it) Martin willingly showed his real ID to anyone who didn't accept his Transnational Republic ID. That doesn't sound all that dishonest to me - surely if the intent was to deceive he wouldn't have shown any real ID? bma -- Benjamin A'Lee - <http://bmalee.eu/~bma/> Secretary, TermiSoc - <http://termisoc.org/> "Graphs of higher degree polynomials have this habit of doing unwanted wiggly things." -- From a Cambridge maths lecture. signature.asc Description: Digital signature
Re: Debian's Linux kernel continues to regress on freedom
On Wed, Sep 12, 2007 at 06:35:18PM +0200, Pierre Habouzit wrote: > I did not took any kind of position on the matter in that thread yet. > But to make you happy I will: there is little point in shipping rfc's > that are mirrored everywhere on the interwebs, and rfc's are clearly > non-free, and do not end up in the final binary package. So there is no > point in no stripping them from the source package as it's not near > being burden for the maintainers, who after all, are the ones that > suffer the "most" of that decision. If nothing else, RFCs shouldn't be shipped in arbitrary packages - there are packages containing nothing but RFCs, and including individual RFCs in other packages is needless duplication. Having packages available (whether in non-free or otherwise) can be useful in terms of having a local copy of the document, but not so vital as to ignore any licencing issues, since (as has been mentioned) they are distributed elsewhere. Also, distributing them without permission to modify them, just because "nobody will ever want to modify them anyway" doesn't really make sense to me. The vast majority of people will never want to modify artwork, or fonts, or other media included in packages, but still Debian requires them to be free because some people might. For that matter, the majority of people will never want to modify any program that they run, but Debian still requires them to be free. Most people will never want to modify RFCs, but some people might (or, at least, create derivative works, translations, etc.), so they should be required to be free or they should stay in the non-free section. -- Benjamin A'Lee <[EMAIL PROTECTED]> http://subvert.org.uk/~bma/ "It's hard to live up to your principles. If it were easy, your principles probably aren't worth a damn anyway." - Mark Pilgrim signature.asc Description: Digital signature
Re: Building packages three times in a row
On Mon, Sep 24, 2007 at 12:54:58AM +0200, Martin Uecker wrote: > Neil Williams <[EMAIL PROTECTED]>: > > This has been covered before - certain upstream macros are among > > many factors that ensure that this is unlikely. I, for one, use such > > macros upstream to indicate the build time of the actual executable > > installed so this will change the binary every time it is built. > > This could be fixed. In every binary that includes the build date in it? There's rather a lot; off the top of my head, Vim does it, and so does the Linux kernel AFAIK. > > You have md5sums and GnuPG signatures on the Release files - I see > > no benefit from bit-matching. > > The build host could be compromised. Not that unlikely. And if the build host was compromised, how would that help any more than md5sums and gpg-signing? With access to the build host, whatever list of bits to match could be changed along with the binary, the md5sum, and the gpg-signature. Anyway, surely the point of hashes like md5, sha1, etc, is that it's much faster to do that than to compare large files bit by bit? -- Benjamin A'Lee <[EMAIL PROTECTED]> http://subvert.org.uk/~bma/ signature.asc Description: Digital signature
Re: Building packages with exact binary matches
On Tue, Sep 25, 2007 at 12:04:15AM +0200, Martin Uecker wrote: > Manoj Srivastava <[EMAIL PROTECTED]> wrote: > >Actually, if you do not trust the path down which a binary > > package flows, you can not use any information down that flow path to > > test your implementation. You need to do a full source audit, and > > build from source -- at which point, you might just install your trused > > binary, instead of trying to verify that the upstream package is the > > same as yours. > > It would be enough when just a few people are actually recompiling the > binaries and compare it to the official debian packages. Then > *everbody* could trust that the packages are not modified, > because any modification would be detected immediatley. This is > only possible with bit-identical binaries. Erm, if I can't trust the Debian Project to create trustworthy packages and verify their integrity, why should I trust anyone else to verify them? And why should anyone trust anyone else? A security system like this would only make sense if everyone did it, and if you're going to recompile every single package to make sure it's trustworthy, then you may as well be using FreeBSD, Gentoo, or similar... You're also assuming that the source code is trustworthy. If the binary packages can be compromised, so can the source packages. -- Benjamin A'Lee <[EMAIL PROTECTED]> http://subvert.org.uk/~bma/ signature.asc Description: Digital signature
