Scripsit Florian Weimer [EMAIL PROTECTED]
This means that it's dangerous to commit yourself to the contents of a
document, using a digital signature, unless you fully understand the
meaning of each byte in the document.
So how do the MD5 sums of .debs end up in a Packages file signed with
the
A cryptographer friend of mine recently attended the NIST Hallowe'en
Hash Bash (http://www.csrc.nist.gov/pki/HashWorkshop/index.html), and
made a few notes in his blog:
http://www.livejournal.com/users/sevenstring/7326.html
His suggestion there was stick to SHA2 (or maybe Whirlpool) for
* Henning Makholm:
Scripsit Florian Weimer [EMAIL PROTECTED]
* Jochen Voss:
I found the example at http://www.cits.rub.de/MD5Collisions/ quite
impressive. They have two different valid PostScript files with
identical MD5 sums. I don't know how much computing time they used,
though.
On Mon, Nov 28, 2005 at 07:07:22PM +1000, Anthony Towns wrote:
(Note that dsum would probably need to become Priority:required,
and possibly Essential:yes, with the complications that entails)
Stick it in dpkg.deb. There's plenty of precedent for that (some
not-so-good, but I think mostly
On Tue, Nov 29, 2005 at 02:20:55PM +0100, Florian Weimer wrote:
* Anthony Towns:
On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote:
In terms of security, there are some better hash functions.
My understanding was that there aren't other hash functions that've had
remotely
On Tue, Nov 29, 2005 at 02:20:55PM +0100, Florian Weimer wrote:
not even be out of the question to find someone who'll sponsor an upload
without rebuilding the .deb. I think it's safe to imagine that there are
developers right now who've done some shady things in the past; is it
that far
Thomas Bushnell BSG [EMAIL PROTECTED] writes:
Goswin von Brederlow [EMAIL PROTECTED] writes:
The archive signing key gives absolutely no integrity ensurance on the
deb package. The only thing it insures is that the file was not
altered _after_ leaving ftp.de.debian.org for the mirrors and/or
Steinar H. Gunderson [EMAIL PROTECTED] writes:
On Sat, Nov 26, 2005 at 09:13:02AM +1000, Anthony Towns wrote:
Moving away from MD5 is certainly not a bad idea, but it's not clear
whether the alternatives are any better. Sure, everyone recommends
SHA-256 at this stage, but nobody can give a
Anthony Towns aj@azure.humbug.org.au writes:
On Fri, Nov 25, 2005 at 12:49:11PM -0800, Thomas Bushnell BSG wrote:
Anthony Towns aj@azure.humbug.org.au writes:
.deb signatures are aimed at giving users some sort of assurance the
package is valid; but when you actually look into it -- at
* Anthony Towns:
On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote:
For the exploits we have seen so far to work, the malicious party
needs upload access to the archive and has to plant a specially
crafted package there, for which they have created an evil twin
package. (Same
Steve Langasek [EMAIL PROTECTED] writes:
On Fri, Nov 25, 2005 at 02:57:36PM +0100, Goswin von Brederlow wrote:
Steve Langasek [EMAIL PROTECTED] writes:
On Thu, Nov 24, 2005 at 07:17:06PM +0100, Goswin von Brederlow wrote:
That's easy: you trust the Packages file to be correct when using
Steinar H. Gunderson [EMAIL PROTECTED] writes:
On Sat, Nov 26, 2005 at 10:47:57AM +1100, Brian May wrote:
Well, even if I know naught about it, it looks to me that having
something signed is better than having the same something not signed.
Sorry, but that's a snake oil rationale.
A: Why do
Anthony Towns aj@azure.humbug.org.au writes:
On Fri, Nov 25, 2005 at 03:13:58PM +0100, Goswin von Brederlow wrote:
You're correct.
And he is also wrong.
That would result in debs with the same name and version but different
md5sums. Something that easily confuses apt-get and people.
And
Hi!
On Tue, Nov 29, 2005 at 02:08:45PM +0100, Goswin von Brederlow wrote:
According to slashdot articles you can generate human readable files
(like the Packages file) with md5sum collision in ~45minutes on a
modern cpu now.
I found the example at http://www.cits.rub.de/MD5Collisions/ quite
* Jochen Voss:
On Tue, Nov 29, 2005 at 02:08:45PM +0100, Goswin von Brederlow wrote:
According to slashdot articles you can generate human readable files
(like the Packages file) with md5sum collision in ~45minutes on a
modern cpu now.
I found the example at
Scripsit Anthony Towns aj@azure.humbug.org.au
On Mon, Nov 28, 2005 at 10:15:34PM +0100, Henning Makholm wrote:
I would expect something like
$ dsum -a sha1 COPYING; sha1sum COPYING
s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI COPYING
sha1sum already exists; and isn't that long. Do you
Scripsit Florian Weimer [EMAIL PROTECTED]
* Jochen Voss:
I found the example at http://www.cits.rub.de/MD5Collisions/ quite
impressive. They have two different valid PostScript files with
identical MD5 sums. I don't know how much computing time they used,
though.
They claim a few hours:
Hi Florian,
On Tue, Nov 29, 2005 at 03:24:54PM +0100, Florian Weimer wrote:
None, many of these examples were created before the collision
generation tools were generally available. The exploit uses some
properties of Postscript files which make them not very desirable for
storing electronic
On Sat, Nov 26, 2005 at 11:10:27PM -0600, Peter Samuelson wrote:
sha256sum () {
(Implementation of -c left as an exercise, etc.)
Hrm, if we're writing our own thing, maybe we should do it properly:
have a single program that can do multiple hash algorithms, have the
default hash be secure,
[Anthony Towns]
gnupg comes close to being this, except for two things: it's got too
many dependencies, and it's command line arguments are overly
complex. A gpgh variant (like gpgv but for hashing) might work,
though. It doesn't support --check, and gpg --print-md md5
/etc/motd has a
Scripsit Peter Samuelson [EMAIL PROTECTED]
For large files, getting a cryptographic checksum is more about reading
blocks off the disk than about CPU time. So it wouldn't be completely
ridiculous to allow sha-1 to remain ambiguous with competing 160-bit
hashes, and have --check check for all
On Mon, Nov 28, 2005 at 10:15:34PM +0100, Henning Makholm wrote:
I would expect something like
$ dsum -a sha1 COPYING; sha1sum COPYING
s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI COPYING
sha1sum already exists; and isn't that long. Do you mean sha256?
Cheers,
aj
signature.asc
On Mon, Nov 28, 2005 at 12:09:33PM -0600, Peter Samuelson wrote:
I still think two-byte prefixes for non-md5-non-sha1 hashes makes some
sense, like s- for sha-256. Avoids the filename encoding issue you
mentioned later (unless we want to encode newlines).
The encoding issues are only for
On Sat, 26 Nov 2005 14:14:38 +0100, Henning Makholm
[EMAIL PROTECTED] wrote:
Scripsit Florian Weimer [EMAIL PROTECTED]
I wouldn't use real base64, though, because it would mean that you can
use its hashed output as a file name.
Good point. One might replace / with _ and omit the final =.
Having
On Sun, Nov 27, 2005 at 02:18:00PM +1000, Anthony Towns wrote:
My understanding was that there aren't other hash functions that've had
remotely similar levels of cryptographic analysis to md5 and sha. IIRC,
the elliptic curve cryptography stuff was supposed to be similarly neat,
until people
In linux.debian.devel, you wrote:
Worse, the existance of a practical md5(A+B+C)=3Dmd5(A+D+C) attack means
that it's not out of the question that there're md5(A+B)=3Dmd5(C+D)
attacks in the hands of particularly well resourced groups (which is
worse, since the version uploaded to the archive
On Sun, Nov 27, 2005 at 12:42:42PM +0100, Steinar H. Gunderson wrote:
On Sun, Nov 27, 2005 at 02:18:00PM +1000, Anthony Towns wrote:
My understanding was that there aren't other hash functions that've had
remotely similar levels of cryptographic analysis to md5 and sha. IIRC,
the elliptic
On Sun, Nov 27, 2005 at 12:42:42PM +0100, Steinar H. Gunderson wrote:
On Sun, Nov 27, 2005 at 02:18:00PM +1000, Anthony Towns wrote:
My understanding was that there aren't other hash functions that've
had remotely similar levels of cryptographic analysis to md5 and
sha. IIRC, the elliptic
On Mon, Nov 28, 2005 at 03:32:21PM +1000, Anthony Towns wrote:
Knapsack cryptograph's provably secure (in that a general solution
is NP),
You mean NP-_complete_. (Sorting is also NP, but not NP-complete. NP
is can be done in polynomial time by a non-deterministic Turing
machine, so anything
On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote:
* Anthony Towns:
On Fri, Nov 25, 2005 at 07:59:40PM +0100, Florian Weimer wrote:
* Anthony Towns:
Moving away from MD5 is certainly not a bad idea, but it's not
clear whether the alternatives are any better. Sure, everyone
On Saturday 26 November 2005 01:13, Anthony Towns wrote:
On Fri, Nov 25, 2005 at 07:59:40PM +0100, Florian Weimer wrote:
* Anthony Towns:
(I'm amazed the security crisis we're having is about deb sigs
*again*, when we're still relying on md5sum which has a public exploit
available
* Anthony Towns:
On Fri, Nov 25, 2005 at 07:59:40PM +0100, Florian Weimer wrote:
* Anthony Towns:
(I'm amazed the security crisis we're having is about deb sigs
*again*, when we're still relying on md5sum which has a public exploit
available now...)
These exploits are irrelevant as far
* Thiemo Seufer:
A: Why do you lock your car up[1]?
B: Because it looks like having it locked is better then not having it
locked.
A: Sorry, but that's a snake oil rationale. Anybody can pick the lock
and break in. Anybody can smash a window and break in. etc.
Wrong, it makes break-ins
On Fri, 25 Nov 2005 12:50:41 -0800, Thomas Bushnell BSG
[EMAIL PROTECTED] wrote:
Goswin von Brederlow [EMAIL PROTECTED] writes:
The archive signing key gives absolutely no integrity ensurance on the
deb package. The only thing it insures is that the file was not
altered _after_ leaving
Scripsit Peter Samuelson [EMAIL PROTECTED]
You may laugh if you wish, but I think it's annoying to have to move to
a hash function whose hexadecimal representation takes 64 bytes, which
doesn't leave much room on an 80-column line to describe what the hash
is hashing. Maybe by the time
* Henning Makholm:
Scripsit Peter Samuelson [EMAIL PROTECTED]
You may laugh if you wish, but I think it's annoying to have to move to
a hash function whose hexadecimal representation takes 64 bytes, which
doesn't leave much room on an 80-column line to describe what the hash
is hashing.
On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote:
So? If SHA256 is so much better, why is that nobody can prove it, or
at least can provide some evidence which supports that claim? The
numbers are bigger is the main argument at this point, which is
awfully similar to the usual
* Steinar H. Gunderson:
On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote:
So? If SHA256 is so much better, why is that nobody can prove it, or
at least can provide some evidence which supports that claim? The
numbers are bigger is the main argument at this point, which is
Scripsit Florian Weimer [EMAIL PROTECTED]
* Henning Makholm:
Why wait for the world to settle? Would there be anything wrong with
writing a sha256sum program that outputs base64 right now?
I wouldn't use real base64, though, because it would mean that you can
use its hashed output as a file
* Henning Makholm:
I wouldn't use real base64, though, because it would mean that you can
use its hashed output as a file name.
Good point. One might replace / with _ and omit the final =.
Having a + in the hash should be safe in most contexts.
It should be replaced with -. Beyond
* Adeodato Simó:
* Florian Weimer [Thu, 24 Nov 2005 18:28:04 +0100]:
Hi,
AFAIK, binary NMus aren't announced on debian-devel-changes.
Binary-only uploads are announced in the appropriate
debian-devel-$ARCH-changes list.
According to
Scripsit Florian Weimer [EMAIL PROTECTED]
* Henning Makholm:
I wouldn't use real base64, though, because it would mean that you can
use its hashed output as a file name.
Good point. One might replace / with _ and omit the final =.
Having a + in the hash should be safe in most contexts.
It
[George Danchev]
Even using weak hash sum algorythms you can easily make the hash
collider life tremendously difficult by simply having more than one
(ok two should be enough) hash sums generated with _different_
(weak?) algorythms on the same entity.
What you have just defined is a new hash
On Fri, Nov 25, 2005 at 11:08:32PM -0600, Peter Samuelson wrote:
You may laugh if you wish, but I think it's annoying to have to move to
a hash function whose hexadecimal representation takes 64 bytes, which
doesn't leave much room on an 80-column line to describe what the hash
is hashing.
On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote:
For the exploits we have seen so far to work, the malicious party
needs upload access to the archive and has to plant a specially
crafted package there, for which they have created an evil twin
package. (Same for attacking one of
[Florian Weimer]
It should be replaced with -. Beyond alphanumerics, only .,
_, - are in the POSIX portable filename character set[1], and
some systems do not allow the character + in file names.
[Henning Makholm]
However there are already plenty of files with + in their names
On Thu, Nov 24, 2005 at 07:17:06PM +0100, Goswin von Brederlow wrote:
That's easy: you trust the Packages file to be correct when using apt,
and it's not verified at all by per-package signatures.
In what way trust and how does that change anything?
At best you can prevent a newer version
On Wed, Nov 23, 2005 at 05:34:41PM +0100, Jeroen van Wolffelaar wrote:
In the archive, 525 out of 283283 .deb's are dpkg-sig'd (0.19%). There
are 8 distinct keys used for those 525 .deb's, seven of which correspond
to DD's[1].
Slightly off the topic, but does this mean the archive contains
* Hamish Moffatt [Fri, 25 Nov 2005 20:34:02 +1100]:
On Wed, Nov 23, 2005 at 05:34:41PM +0100, Jeroen van Wolffelaar wrote:
In the archive, 525 out of 283283 .deb's are dpkg-sig'd (0.19%). There
are 8 distinct keys used for those 525 .deb's, seven of which correspond
to DD's[1].
Slightly
Hi,
Anthony Towns wrote:
The problem is that using gzip and ar is complicated, which adds
possibilities for errors. You might find yourself not putting the deb
together again and getting false signature mismatches, or worse, you
might find yourself only verifying part of the .deb, and having
Anthony Towns aj@azure.humbug.org.au writes:
On Thu, Nov 24, 2005 at 06:28:04PM +0100, Florian Weimer wrote:
If you just want to check hashes, you should just use changes files. If
you _actually_ want to check hashes, and this isn't just a thought
experiment, working out a usable way to
Steve Langasek [EMAIL PROTECTED] writes:
On Thu, Nov 24, 2005 at 07:17:06PM +0100, Goswin von Brederlow wrote:
That's easy: you trust the Packages file to be correct when using apt,
and it's not verified at all by per-package signatures.
In what way trust and how does that change
Anthony Towns aj@azure.humbug.org.au writes:
On Thu, Nov 24, 2005 at 07:47:58PM +0100, Goswin von Brederlow wrote:
Anthony Towns aj@azure.humbug.org.au writes:
On Wed, Nov 23, 2005 at 09:18:40PM +0100, Goswin von Brederlow wrote:
Use 1: I have this deb in my apt-move mirror and I want to
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
On Thu, 24 Nov 2005, Anthony Towns wrote:
On Thu, Nov 24, 2005 at 07:39:57AM +0100, Marc Haber wrote:
Uh, packages not uploaded to the official Debian archive can do whatever
they want.
It would, however, be convenient to be able to
Simon Richter [EMAIL PROTECTED] writes:
IF this means we can switch the effort to a detached signature that is more
powerful than a .changes file (or we are allowed to have multiple signatures
in a .changes file),
That is already possible with gnupg, just not well-documented; I'm not
entirely
On Fri, Nov 25, 2005 at 03:22:37PM +0100, Goswin von Brederlow wrote:
A signature in the deb by a random developer is as trustworthy as the
changes file and you already trust that. So we are going from snakeoil
to snakoil. No harm done.
It's not the same, actually. A signature in a .deb needs
On 11/25/05, Matthew Palmer [EMAIL PROTECTED] wrote:
Of course, using the signature on the .changes to verify the .debs
independent from the archive at some later date is a nice side-benefit, but
one which suffers from the same key-lifetime issues as in-deb signatures,
What exactly is this key
Matthew Palmer [EMAIL PROTECTED] writes:
On Fri, Nov 25, 2005 at 03:22:37PM +0100, Goswin von Brederlow wrote:
A signature in the deb by a random developer is as trustworthy as the
changes file and you already trust that. So we are going from snakeoil
to snakoil. No harm done.
It's not the
Olaf van der Spek [EMAIL PROTECTED] writes:
On 11/25/05, Matthew Palmer [EMAIL PROTECTED] wrote:
Of course, using the signature on the .changes to verify the .debs
independent from the archive at some later date is a nice side-benefit, but
one which suffers from the same key-lifetime issues
On Fri, 25 Nov 2005, Anthony Towns wrote:
(I'm amazed the security crisis we're having is about deb sigs
*again*, when we're still relying on md5sum which has a public exploit
available now...)
Do you really want a thread about how we should switch everything to SHA-512
or something like that?
* Anthony Towns:
(I'm amazed the security crisis we're having is about deb sigs
*again*, when we're still relying on md5sum which has a public exploit
available now...)
These exploits are irrelevant as far as the Debian archive is
concerned. (And that's not because hardly any sarge user
Anthony Towns aj@azure.humbug.org.au writes:
.deb signatures are aimed at giving users some sort of assurance the
package is valid; but when you actually look into it -- at least in
Debian's circumstances -- those signatures can't actually give any
meaningful assurance for any specific
Goswin von Brederlow [EMAIL PROTECTED] writes:
The archive signing key gives absolutely no integrity ensurance on the
deb package. The only thing it insures is that the file was not
altered _after_ leaving ftp.de.debian.org for the mirrors and/or
user. In no way does it prevent altering the
On Fri, Nov 25, 2005 at 03:13:58PM +0100, Goswin von Brederlow wrote:
You're correct.
And he is also wrong.
That would result in debs with the same name and version but different
md5sums. Something that easily confuses apt-get and people.
And yet, somehow people manage partial cross-grades
On Fri, Nov 25, 2005 at 12:49:11PM -0800, Thomas Bushnell BSG wrote:
Anthony Towns aj@azure.humbug.org.au writes:
.deb signatures are aimed at giving users some sort of assurance the
package is valid; but when you actually look into it -- at least in
Debian's circumstances -- those
On Fri, Nov 25, 2005 at 02:27:23PM -0200, Henrique de Moraes Holschuh wrote:
Well, the email about the new bin-NMU structure implied that it was fixed
for *NMUs done through that structure*.
Then the email was wrong. *shrug*
My objection is that it's *useless* for *Debian*. Debian has
On Fri, Nov 25, 2005 at 07:59:40PM +0100, Florian Weimer wrote:
* Anthony Towns:
(I'm amazed the security crisis we're having is about deb sigs
*again*, when we're still relying on md5sum which has a public exploit
available now...)
These exploits are irrelevant as far as the Debian
On Sat, Nov 26, 2005 at 08:48:45AM +1000, Anthony Towns wrote:
On Fri, Nov 25, 2005 at 03:13:58PM +0100, Goswin von Brederlow wrote:
You're correct.
And he is also wrong.
That would result in debs with the same name and version but different
md5sums. Something that easily confuses
On Sat, Nov 26, 2005 at 09:13:02AM +1000, Anthony Towns wrote:
Moving away from MD5 is certainly not a bad idea, but it's not clear
whether the alternatives are any better. Sure, everyone recommends
SHA-256 at this stage, but nobody can give a rationale.
MD5 is broken; SHA-1 is where MD5 was
Thiemo == Thiemo Seufer [EMAIL PROTECTED] writes:
Well, even if I know naught about it, it looks to me that having
something signed is better than having the same something not signed.
Thiemo Sorry, but that's a snake oil rationale.
A: Why do you lock your car up[1]?
B: Because
On Sat, Nov 26, 2005 at 10:47:57AM +1100, Brian May wrote:
Well, even if I know naught about it, it looks to me that having
something signed is better than having the same something not signed.
Sorry, but that's a snake oil rationale.
A: Why do you lock your car up[1]?
Because it makes it
On Fri, Nov 25, 2005 at 02:57:36PM +0100, Goswin von Brederlow wrote:
Steve Langasek [EMAIL PROTECTED] writes:
On Thu, Nov 24, 2005 at 07:17:06PM +0100, Goswin von Brederlow wrote:
That's easy: you trust the Packages file to be correct when using apt,
and it's not verified at all by
* Steve Langasek [Fri, 25 Nov 2005 17:19:01 -0800]:
how arbitrary users are supposed to verify whether a given key is in the
keyring. The debian-keyring package doesn't get updated every time there's
a key added or removed, and the web interface to keyring.debian.org doesn't
provide any
Brian May wrote:
Thiemo == Thiemo Seufer [EMAIL PROTECTED] writes:
Well, even if I know naught about it, it looks to me that having
something signed is better than having the same something not signed.
Thiemo Sorry, but that's a snake oil rationale.
A: Why do you lock
On Fri, Nov 25, 2005 at 05:19:01PM -0800, Steve Langasek wrote:
Oh, and BTW, check the IPs of ftp-master.debian.org and
keyring.debian.org...
Well, at this moment those are distinct, because ftp-master is
temporarily hosted on spohr.debian.org, and not on raff.debian.org,
where keyring.d.o
[Steinar H. Gunderson]
All three might eventually be truly broken, but you can bet that MD5
will be the first to go. If you use SHA-256 today instead of MD5, you
probably buy yourself a few extra years, which you can use to smooth
out the transition to the next hash function when the world
On Thu, Nov 24, 2005 at 12:56:15AM +0100, Marc 'HE' Brockschmidt wrote:
I will fill a whishlist bugreport against debuild to support dpkg-sig
side by side with debuild.
There is already #247825. #247824 is the wishlist bug for
dpkg-buildpackage support.
Indeed, I spotted them just after the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John Hasler [EMAIL PROTECTED] writes:
Marc Haber writes:
So, most of the DD's do not care about security at all.
I think that DD's do not use dpkg-sig and debsigs because they believe them
to be hard to use and not supported by the
On Thu, 24 Nov 2005 10:51:55 +, Roger Leigh
[EMAIL PROTECTED] wrote:
John Hasler [EMAIL PROTECTED] writes:
Marc Haber writes:
So, most of the DD's do not care about security at all.
I think that DD's do not use dpkg-sig and debsigs because they believe them
to be hard to use and not
Marc Haber [EMAIL PROTECTED] wrote:
On Thu, 24 Nov 2005 10:51:55 +, Roger Leigh
[EMAIL PROTECTED] wrote:
John Hasler [EMAIL PROTECTED] writes:
Marc Haber writes:
So, most of the DD's do not care about security at all.
I think that DD's do not use dpkg-sig and debsigs because they
On Thu, Nov 24, 2005 at 02:11:45PM +1100, Matthew Palmer wrote:
On Thu, Nov 24, 2005 at 11:54:33AM +1000, Anthony Towns wrote:
On Wed, Nov 23, 2005 at 04:37:05PM -0200, Henrique de Moraes Holschuh wrote:
On Thu, 24 Nov 2005, Anthony Towns wrote:
Personally, I think it's cryptographic
On Thursday, November 24, 2005 11:17 AM, Wouter Verhelst [EMAIL PROTECTED]
wrote:
On Thu, Nov 24, 2005 at 02:11:45PM +1100, Matthew Palmer wrote:
[...]
On that score, the description for d-d-c says that it includes
buildd logs,
Then that description is wrong. It never did include buildd
On Thu, Nov 24, 2005 at 11:38:45AM -, Adam D. Barratt wrote:
On Thursday, November 24, 2005 11:17 AM, Wouter Verhelst [EMAIL PROTECTED]
wrote:
On Thu, Nov 24, 2005 at 02:11:45PM +1100, Matthew Palmer wrote:
[...]
On that score, the description for d-d-c says that it includes
buildd
* Matthew Palmer [Thu, 24 Nov 2005 22:54:58 +1100]:
Sorry, that was a massive typo on my part. I thought buildd output, and
wrote buildd logs when I meant buildd .changes files. My question, as
amended, though, still holds -- are the .changes associated with the upload
of autobuilt packages
On Thu, 24 Nov 2005, Anthony Towns wrote:
On Wed, Nov 23, 2005 at 04:37:05PM -0200, Henrique de Moraes Holschuh wrote:
On Thu, 24 Nov 2005, Anthony Towns wrote:
Personally, I think it's cryptographic snake oil, at least in so far
A signed deb has a seal of procedence and allows one to
On Thu, 24 Nov 2005, Anthony Towns wrote:
You can already use release signatures for this. Further, changing the
deb after upload would make it much more difficult to check the deb was
what was uploaded -- you can no longer just use md5sum, you've instead
got to use special tools.
While the
Hi,
Henrique de Moraes Holschuh wrote:
Well, assuming .changes is not snake-oil, then why should in-deb sigs be
called snake-oil? After all, according to you they essentially do the same
job.
Not exactly. .changes files say that the archive should be changed. If
the archive were to accept
* Anthony Towns:
Personally, I think it's cryptographic snake oil, at least in so far
as it relates to Debian. I remain interested in seeing any realistic
demonstration of how a Debian user could reasonably rely on them for
any practical assurance.
The assurance doesn't come from the
Anthony Towns aj@azure.humbug.org.au writes:
On Thu, Nov 24, 2005 at 09:09:21AM +1100, Matthew Palmer wrote:
2) A signature from dinstall saying this package was installed in the
Debian archive would provide a means of automatic assurance of the source
of a binary package, when I'm putting
Anthony Towns aj@azure.humbug.org.au writes:
On Thu, Nov 24, 2005 at 02:31:22PM +1100, Matthew Palmer wrote:
Then there's the opposite argument about why not do that inside the .deb?.
Simple answers: unnecessary bloat, unwarranted feeling of security
leading to bad decisions.
Where do you
Goswin von Brederlow [EMAIL PROTECTED] wrote:
Anthony Towns aj@azure.humbug.org.au writes:
deb after upload would make it much more difficult to check the deb was
what was uploaded -- you can no longer just use md5sum, you've instead
got to use special tools.
So? Is that so bad?
Also so
Simon Richter [EMAIL PROTECTED] writes:
Hi,
Henrique de Moraes Holschuh wrote:
Well, assuming .changes is not snake-oil, then why should in-deb sigs be
called snake-oil? After all, according to you they essentially do the same
job.
Not exactly. .changes files say that the archive should
Anthony Towns aj@azure.humbug.org.au writes:
On Wed, Nov 23, 2005 at 09:18:40PM +0100, Goswin von Brederlow wrote:
Use 1: I have this deb in my apt-move mirror and I want to know if it
was compromised on yesterdays breakin
Boot a clean system with debian keyring and check all deb
Frank Küster [EMAIL PROTECTED] writes:
If such a signature mechanism is implemented, dinstall could also append
a copy of the filelist, with updated md5sums. I'm not familiar with the
ar format, but can one restore the old md5sum when you unpack the deb,
remove the additional signature, and
* Florian Weimer [Thu, 24 Nov 2005 18:28:04 +0100]:
Hi,
AFAIK, binary NMus aren't announced on debian-devel-changes.
Binary-only uploads are announced in the appropriate
debian-devel-$ARCH-changes list.
--
Adeodato Simó dato at net.com.org.es
Debian
On Thu, Nov 24, 2005 at 07:39:57AM +0100, Marc Haber wrote:
Uh, packages not uploaded to the official Debian archive can do whatever
they want.
It would, however, be convenient to be able to upload a package to
Debian and to be able to use the same package for different things.
As far as
On Thu, 24 Nov 2005, Anthony Towns wrote:
On Thu, Nov 24, 2005 at 07:39:57AM +0100, Marc Haber wrote:
Uh, packages not uploaded to the official Debian archive can do whatever
they want.
It would, however, be convenient to be able to upload a package to
Debian and to be able to use the
On Thu, Nov 24, 2005 at 06:44:37PM +1100, Matthew Palmer wrote:
On Thu, Nov 24, 2005 at 03:48:15PM +1000, Anthony Towns wrote:
On Thu, Nov 24, 2005 at 02:31:22PM +1100, Matthew Palmer wrote:
I think the final judgment in this issue is going to come down to personal
taste and needs more
On Thu, Nov 24, 2005 at 10:43:38AM -0200, Henrique de Moraes Holschuh wrote:
On Thu, 24 Nov 2005, Anthony Towns wrote:
On Wed, Nov 23, 2005 at 04:37:05PM -0200, Henrique de Moraes Holschuh wrote:
On Thu, 24 Nov 2005, Anthony Towns wrote:
Personally, I think it's cryptographic snake oil,
On Thu, Nov 24, 2005 at 07:47:58PM +0100, Goswin von Brederlow wrote:
Anthony Towns aj@azure.humbug.org.au writes:
On Wed, Nov 23, 2005 at 09:18:40PM +0100, Goswin von Brederlow wrote:
Use 1: I have this deb in my apt-move mirror and I want to know if it
was compromised on yesterdays
1 - 100 of 157 matches
Mail list logo
