dpkg-sig support wanted?

[Marc 'HE' Brockschmidt]

Heya,

Today (or last night, whatever), the dak installation on ftp-master was
changed to not accept packages that include more than 3 parts, which are
usually the binary version and the compressed control and data
tarballs. This means that signed binary packages are rejected.

This is not the first time that this change to the dak scripts was
activated. We had this problem for a few days some months ago, but the
change was reverted. There was no discussion about this issue (and why
signed binary packages need to be rejected) since then. There was no
warning or indication that this check would be activated again in the
last week.

As I'm responsible for most of dpkg-sig's code (and planned to do some
more work in the next two months) I'd like to know if anyone cares about
using these binary signatures or if I can invest my time into something
that's a bit more satisfying (== non-Debian stuff). As the ftp-masters
and the dpkg maintainers seem to have no interest in the whole thing,
I'm beginning to doubt that it's sensible to work on dpkg-sig.

Marc
-- 
Fachbegriffe der Informatik - Einfach erklärt
138: OSPF
   One Single Point of Failure (Pascal Gienger)


pgp3PbiBsGLFY.pgp
Description: PGP signature

Re: dpkg-sig support wanted?

[Petter Reinholdtsen]

[Marc 'HE' Brockschmidt]
> I'd like to know if anyone cares about using these binary signatures

I can not really say if I care or not, as I do not really know what
these binary signatures are.  Care to send URL to pages explaining the
topic?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[James Vega]

On Tue, Nov 22, 2005 at 05:41:05PM +0100, Petter Reinholdtsen wrote:
> 
> [Marc 'HE' Brockschmidt]
> > I'd like to know if anyone cares about using these binary signatures
> 
> I can not really say if I care or not, as I do not really know what
> these binary signatures are.  Care to send URL to pages explaining the
> topic?

As per 'apt-cache show dpkg-sig':

Website is http://dpkg-sig.turmzimmer.net/

James
-- 
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>


pgpEBswLX1uTA.pgp
Description: PGP signature

Re: dpkg-sig support wanted?

[John Hasler]

Marc 'HE' Brockschmidt writes:
> I'd like to know if anyone cares about using these binary signatures

I do.
-- 
John Hasler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[martin f krafft]

also sprach Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> [2005.11.22.1650 +0100]:
> As I'm responsible for most of dpkg-sig's code (and planned to do
> some more work in the next two months) I'd like to know if anyone
> cares about using these binary signatures or if I can invest my
> time into something that's a bit more satisfying (== non-Debian
> stuff). As the ftp-masters and the dpkg maintainers seem to have
> no interest in the whole thing, I'm beginning to doubt that it's
> sensible to work on dpkg-sig.

I fully support dpkg-sig and do not appreciate having to hear that
a decision was made without the giving the collective of developers
a chance to voice their opinions before.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"man soll nicht in kirchen gehn, wenn man reine luft atmen will."
 - friedrich nietzsche


signature.asc
Description: Digital signature (GPG/PGP)

Re: dpkg-sig support wanted?

[Matthew Palmer]

On Tue, Nov 22, 2005 at 04:50:02PM +0100, Marc 'HE' Brockschmidt wrote:
> As I'm responsible for most of dpkg-sig's code (and planned to do some
> more work in the next two months) I'd like to know if anyone cares about
> using these binary signatures or if I can invest my time into something
> that's a bit more satisfying (== non-Debian stuff).

I'm keenly interested in per-package signatures for Debian packages -- I
think they're a great idea and it's a pity that they haven't received more
interest.

I've never seen dpkg-sig mentioned before, only debsigs, so I'm not familiar
with the tool itself, but the concept is one that needs a lot more exposure.

- Matt


signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Brian May]

> "Matthew" == Matthew Palmer <[EMAIL PROTECTED]> writes:

Matthew> I'm keenly interested in per-package signatures for
Matthew> Debian packages -- I think they're a great idea and it's
Matthew> a pity that they haven't received more interest.

Same here.

I would really like to see all packages signed, not just the source
code and not just the archive (if any) they came from.

I see advantages:

* ability to check downloaded binary package even if it no longer
  exists in latest archive.

* ability to trace the source of a binary package in a secure way,
  whether it was built by a maintainer, automatically built by an
  autobuilder (which one?), or built by some 3rd party.

  yes - I realize some people consider automatic signing by an
  autobuilder to be "insecure" - however I think it is more secure
  then not having any signature - when deciding on how much you trust
  it you need to take into account the source. Besides, I believe the
  archive is already signed automatically anyway.

* this can occur without trying to look up the *.changes file
  (assuming it still exists - for packages never uploaded to Debian,
  maybe not).

* others I am too lazy to think of.

Matthew> I've never seen dpkg-sig mentioned before, only debsigs,
Matthew> so I'm not familiar with the tool itself, but the concept
Matthew> is one that needs a lot more exposure.

I would speculate debsigs got a name change to dpkg-sig. Can somebody
confirm or deny?
-- 
Brian May <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Marc 'HE' Brockschmidt]

Heya,

After discussing this in IRC, we agreed that I give a short overview
about the important stuff. As I'm quite lazy, I'm quoting James Troup
for the history bits:

 was written for Ubuntu, specifically because they were activating
 data.tar.bz2 support in debs.  as a side effect it also enforced
 certain constraints on the layout of .ars simply becuase of the way the
 code was written.  this was tested on everything in ubuntu and didn't
 trip anything.  the code got ported to Debian shortly before the
 release of sarge 
 at that point, it became apparent it broke dpkg-sig signed debs.
 after various conversations, I disabled the check, because amongst
 other things making changes like that just prior to release probably
 wasn't clever.  however, I didn't sufficently comment WHY the check was
 deactivated in the code, I just said "till sarge is released" or
 similar
 which is my bad, and I apologize.  in any event, sarge has
 obviously been and gone, and the check got re-enabled as part of a
 cleanup of the code on sphor vs. cvs. 

Today, some people ranted in IRC about the fact that packages with
binary signatures were rejected again. As I believed that someone
activated these checks while knowing that they break packages with
binary signatures, I was pretty pissed off. I remembered the comment to
be something like "breaks dpkg-sig, deactivated for now", but the CVS [1]
shows that was wrong. Anyway, I want to apologize for carrying this to
-devel directly.

OK, now to the good parts: Joerg Jaspert planned to provide a better
version of the problematic check anyway (also validating the binary
signatures) and will try to finish them as soon as possible. I'll try to
be useful in respect to that, at least as useful as I can be. And now
we're all happy again. Yay!

Marc

Footnotes: 
[1]  http://cvs.debian.org/dak/jennifer?root=dak&r1=1.56&r2=1.57

-- 
BOFH #139:
UBNC (user brain not connected)


pgpARUHMfjp3A.pgp
Description: PGP signature

Re: dpkg-sig support wanted?

[Marc 'HE' Brockschmidt]

Brian May <[EMAIL PROTECTED]> writes:
>> I've never seen dpkg-sig mentioned before, only debsigs,
>> so I'm not familiar with the tool itself, but the concept
>> is one that needs a lot more exposure.
> I would speculate debsigs got a name change to dpkg-sig. Can somebody
> confirm or deny?

No. dpkg-sig is a completly independent application (though some ideas
were taken from debsigs)

Marc
-- 
Fachbegriffe der Informatik - Einfach erklärt (120: INN 2.x)
   INN 2.x ist wie Fertig-Spaghetti aus der Tüte. Schmeckt lecker und ist im
   Grunde ganz einfach zuzubereiten. Trotzdem muß man ständig umrühren,
   damit's nicht anbrennt. (Andreas M. Kirchwitz)


pgppRAVozxPvv.pgp
Description: PGP signature

Re: dpkg-sig support wanted?

[Matthew Palmer]

On Wed, Nov 23, 2005 at 10:29:32AM +1100, Brian May wrote:
> I would speculate debsigs got a name change to dpkg-sig. Can somebody
> confirm or deny?

As Mark said, it's not a name change.  The FAQ on the dpkg-sig site
(http://dpkg-sig.turmzimmer.net/) has more info.

- Matt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Florian Weimer]

* Marc Brockschmidt:

> Today (or last night, whatever), the dak installation on ftp-master was
> changed to not accept packages that include more than 3 parts, which are
> usually the binary version and the compressed control and data
> tarballs. This means that signed binary packages are rejected.

This is a pity.  I think dpkg-sig is an important step into the right
direction: providing more assurances about package integrity to our
users.

I'm confused about the status of the dak change, though.  The dak
mirror on merkel does not show any modifiations of the jennifer script
since May 31.  The diff at
 shows
that the additional check was *removed*, not *added* more than a week
ago.  Therefore, the dak CVS does not reflect what's actually in
production use.

Since there is no way for Debian Developers to review the way Debian
packages are created (and it's totally out of question for end users),
something that provides DD-to-user package signatures at least in some
cases is very desirable indeed.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Anthony Towns]

On Wed, Nov 23, 2005 at 11:33:47AM +0100, Florian Weimer wrote:
> * Marc Brockschmidt:
> > Today (or last night, whatever), the dak installation on ftp-master was
> > changed to not accept packages that include more than 3 parts, which are
> > usually the binary version and the compressed control and data
> > tarballs. This means that signed binary packages are rejected.
> This is a pity.  I think dpkg-sig is an important step into the right
> direction: providing more assurances about package integrity to our
> users.

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.

> since May 31.  The diff at
>  shows
> that the additional check was *removed*, not *added* more than a week
> ago.

Yes; CVS was corrupted in May and hadn't been updated 'til the other
week. http://azure.humbug.org.au/~aj/blog/2005/11/16#2005-11-16-dak

> Since there is no way for Debian Developers to review the way Debian
> packages are created (and it's totally out of question for end users),

buildd.debian.org gives full logs, to developers or users.

> something that provides DD-to-user package signatures at least in some
> cases is very desirable indeed.

debian-devel-changes provides this.

Cheers,
aj



signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Jeroen van Wolffelaar]

On Tue, Nov 22, 2005 at 04:50:02PM +0100, Marc 'HE' Brockschmidt wrote:
> As I'm responsible for most of dpkg-sig's code (and planned to do some
> more work in the next two months) I'd like to know if anyone cares about
> using these binary signatures or if I can invest my time into something
> that's a bit more satisfying (== non-Debian stuff). As the ftp-masters
> and the dpkg maintainers seem to have no interest in the whole thing,
> I'm beginning to doubt that it's sensible to work on dpkg-sig.

Just to provide some statistics about dpkg-sig usage, as I got curious
about it too:

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].

I'm not going to interpret these numbers, as it's close to impossible to
do so objectively.

--Jeroen

[1] Interested DD's can look into merkel:~jeroen/dpkg-sig how I got these
numbers

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Marc Haber]

On Wed, 23 Nov 2005 17:34:41 +0100, Jeroen van Wolffelaar
<[EMAIL PROTECTED]> wrote:
>On Tue, Nov 22, 2005 at 04:50:02PM +0100, Marc 'HE' Brockschmidt wrote:
>> As I'm responsible for most of dpkg-sig's code (and planned to do some
>> more work in the next two months) I'd like to know if anyone cares about
>> using these binary signatures or if I can invest my time into something
>> that's a bit more satisfying (== non-Debian stuff). As the ftp-masters
>> and the dpkg maintainers seem to have no interest in the whole thing,
>> I'm beginning to doubt that it's sensible to work on dpkg-sig.
>
>Just to provide some statistics about dpkg-sig usage, as I got curious
>about it too:
>
>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].

So, most of the DD's do not care about security at all. Why does
Debian have a reputation of being so secure?

Otoh, what does the project gain by making 0.19 % of our debs in the
archive less secure than they are now? Are we that damager driven that
we deliberately reduce our security just to gain an uniform level?

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: dpkg-sig support wanted?

[Erinn Clark]

* Marc Haber <[EMAIL PROTECTED]> [2005:11:23 18:40 +0100]: 
> On Wed, 23 Nov 2005 17:34:41 +0100, Jeroen van Wolffelaar
> >Just to provide some statistics about dpkg-sig usage, as I got curious
> >about it too:
> >
> >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].
> 
> So, most of the DD's do not care about security at all. Why does
> Debian have a reputation of being so secure?

Yet just today you filed a bug (#340403) for documentation to be
included in the package since you were unable to explain dpkg-sig's
strengths. How is it possible for you to claim something is more secure
when you don't understand it well enough to say how it's different?

-- 
off the chain like a rebellious guanine nucleotide


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Mikhail Sobolev]

On Tue, Nov 22, 2005 at 04:50:02PM +0100, Marc 'HE' Brockschmidt wrote:
> As I'm responsible for most of dpkg-sig's code (and planned to do some
> more work in the next two months) I'd like to know if anyone cares about
> using these binary signatures or if I can invest my time into something
> that's a bit more satisfying (== non-Debian stuff). As the ftp-masters
> and the dpkg maintainers seem to have no interest in the whole thing,
> I'm beginning to doubt that it's sensible to work on dpkg-sig.
I'd be very interested in the whole idea.

--
Misha

PS  I'm not a DD


signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Adam Heath]

On Wed, 23 Nov 2005, Marc Haber 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].
>
> So, most of the DD's do not care about security at all. Why does
> Debian have a reputation of being so secure?

Ah, you're a gloom-and-doomer.

There's been no push.  No default.  No message saying that it's acceptable and
wanted to sign debs.

Most people(not just DD) take the defaults, the easy way out.  These numbers
will increase when the default is to sign.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Olaf van der Spek]

On 11/23/05, Marc Haber <[EMAIL PROTECTED]> 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].
>
> So, most of the DD's do not care about security at all. Why does
> Debian have a reputation of being so secure?

Security is more than package signatures.

Re: dpkg-sig support wanted?

[Henrique de Moraes Holschuh]

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 track the path it
made through the system, and who changed it.  It ties a non-trustable
timestamp to every singed step in that path, but that has limited use.
It allows one to verify against tampering of the data along that path.

It does no more.  Nobody who really knows what he's talking about claimed
that it did.

I do claim that a criptographic seal of procedence and non-tampering IS
valuable information, and also that dpkg-sig delivers that information in a
much more usable and universal way than anything else we have currently.

> > something that provides DD-to-user package signatures at least in some
> > cases is very desirable indeed.
> 
> debian-devel-changes provides this.

Not in a very useable form, and only for Debian packages uploaded to the
official Debian archive.  This is hardly good enough.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[John Hasler]

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 infrastructure or by policy.
-- 
John Hasler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Henrique de Moraes Holschuh]

On Wed, 23 Nov 2005, 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].
> 
> I'm not going to interpret these numbers, as it's close to impossible to
> do so objectively.

Well, *I* can speak for myself, and all my packages would have been signed
had I known I am allowed to upload signed packages to Debian, which I
didn't.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[John Hasler]

Olaf van der Spek writes:
> Security is more than package signatures.

What is your specific proposal?
-- 
John Hasler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Henrique de Moraes Holschuh]

On Wed, 23 Nov 2005, John Hasler wrote:
> Olaf van der Spek writes:
> > Security is more than package signatures.
> 
> What is your specific proposal?

Don't go there, or at least start another thread to do so. Olaf is correct,
signed packages are not enough and we have reharsed that discursion a lot.

This doesn't mean that signed packages are useless, far from it.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Olaf van der Spek]

On 11/23/05, John Hasler <[EMAIL PROTECTED]> wrote:
> Olaf van der Spek writes:
> > Security is more than package signatures.
>
> What is your specific proposal?

I don't have one. But I don't see how that's relevant.

Re: dpkg-sig support wanted?

[Goswin von Brederlow]

Anthony Towns  writes:

> On Wed, Nov 23, 2005 at 11:33:47AM +0100, Florian Weimer wrote:
>> * Marc Brockschmidt:
>> > Today (or last night, whatever), the dak installation on ftp-master was
>> > changed to not accept packages that include more than 3 parts, which are
>> > usually the binary version and the compressed control and data
>> > tarballs. This means that signed binary packages are rejected.
>> This is a pity.  I think dpkg-sig is an important step into the right
>> direction: providing more assurances about package integrity to our
>> users.
>
> 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.

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
  signatures.

Use 2: I have this Ubuntu CD and want to know which debs are from
   debian and which got recompiled

  Look for all debs that have a deb signature of the debian archive
  (to be added to dinstall at some point).

Use 3: The debian servers were compromised and the security team takes
   too long to check the archive for my taste

  Being a normal user I obviously have no mail archive of all the
  old changes files laying around so that road is closed. But everyone
  has a Debian stable CD with keyring. See Use 1.

Use 4: The Debian Archive Key has expired yet again, like every year
   or the Release.gpg file is out of sync as so often on some
   mirrors and I still want to verify debs.

  Check deb signatures against the keyring instead of the Release.gpg
  check in apt.


Use 1, 3 and 4 rely on a manual signature of each deb. One suggestion
is to add this to debsign so the only change for developers is that
gpg asks for the passphrase more often. Use 2 would require an
automatic signature by the archive.

>> since May 31.  The diff at
>>  shows
>> that the additional check was *removed*, not *added* more than a week
>> ago.
>
> Yes; CVS was corrupted in May and hadn't been updated 'til the other
> week. http://azure.humbug.org.au/~aj/blog/2005/11/16#2005-11-16-dak
>
>> Since there is no way for Debian Developers to review the way Debian
>> packages are created (and it's totally out of question for end users),
>
> buildd.debian.org gives full logs, to developers or users.

While the log contains the md5sum of each build deb it does not
contain any signature against tampering. Same goes for the mail
exchange between the buildd and admin for all the admins that sign by
mail.

Tampered debs can be uploaded by sending a fake mail to the admin and
filtering out his responce. A deb signature of the buildd and a
subsequent dak check would prevent this.

>> something that provides DD-to-user package signatures at least in some
>> cases is very desirable indeed.
>
> debian-devel-changes provides this.

That covers only the sourcefull uploads and the arch specific -changes
lists are not archived and therefore useless for non constant
monitoring.

> Cheers,
> aj

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Matthew Garrett]

Goswin von Brederlow <[EMAIL PROTECTED]> wrote:

> Use 2: I have this Ubuntu CD and want to know which debs are from
>debian and which got recompiled
> 
>   Look for all debs that have a deb signature of the debian archive
>   (to be added to dinstall at some point).

The answer is "all of them", so this one's not very compelling.

-- 
Matthew Garrett | [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Peter Samuelson]

[Erinn Clark]
> Yet just today you filed a bug (#340403) for documentation to be
> included in the package since you were unable to explain dpkg-sig's
> strengths. How is it possible for you to claim something is more secure
> when you don't understand it well enough to say how it's different?

That's unfair and you know it.  It seems he *did* educate himself about
dpkg-sig: "I had to look for a while to find the dpkg-sig FAQ on the
web page."  It is perfectly reasonable to want users to have easy
access to this information, given the rather confusing array of
signature-related packages and options in Debian packaging.

Not knowing the relative advantages of dpkg-sig versus debsigs is
hardly the same thing as being unqualified to speak about the reasons
(or lack thereof) to support signed .debs.  And, from what I
understand, the dak change which proved so contentious broke both
equally.  (Whether Andreas's script counted packages signed with
debsigs as well as those signed with dpkg-sig, I don't know, as I don't
have access to it.)

I do think a feature comparison and compatibility matrix would be
useful to have, between dpkg-buildpackage/debsign (for signing .changes
and .dsc files), debsigs (for signing .deb files), dpkg-sig (for
signing and verifying .deb files) and debsig-verify (for verifying .deb
files).


signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Peter Samuelson]

  [Goswin von Brederlow]
> > Use 2: I have this Ubuntu CD and want to know which debs are from
> >debian and which got recompiled
> > 
> >   Look for all debs that have a deb signature of the debian archive
> >   (to be added to dinstall at some point).

[Matthew Garrett]
> The answer is "all of them", so this one's not very compelling.

What?  All Ubuntu .deb files went through ftp-master.debian.org at some
point?  I know you can't actually mean that.  Hmmm, perhaps you meant
"none of them"?  If so, that's an Ubuntu-specific answer, because even
if Ubuntu recompiles all packages, many Debian derivative distributions
do not.

Or did you mean signatures on individual debs are not useful for this
purpose since one could instead simply archive the Packages and Release
files for Debian unstable every day between one Ubuntu release and the
next?  While possible, this has approximately the same absurdity factor
as asking users to subscribe to debian-devel-changes and keep enough
mail archives around to verify developer signatures *that* way.  (Yes,
believe it or not, that has actually been proposed!)


signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Marc Haber]

On Wed, 23 Nov 2005 17:03:51 -0200, Henrique de Moraes Holschuh
<[EMAIL PROTECTED]> wrote:
>This doesn't mean that signed packages are useless, far from it.

They are useless at the moment. They cannot be uploaded.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: dpkg-sig support wanted?

[Marc Haber]

On Wed, 23 Nov 2005 12:11:20 -0600, John Hasler <[EMAIL PROTECTED]>
wrote:
>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 infrastructure or by policy.

dpkg-sig is harly "hard to use". Even I learned how to use it in two
minutes from reading the man page. And I am known to be stupid.

People finding stuff like dpkg-sig and debsigs "hard to use" do not
care about security. Thanks for proving my point.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: dpkg-sig support wanted?

[Marc Haber]

On Wed, 23 Nov 2005 12:09:34 -0600 (CST), Adam Heath
<[EMAIL PROTECTED]> wrote:
>There's been no push.  No default.  No message saying that it's acceptable and
>wanted to sign debs.

So Debian doesn't care about security. If we did, we would have an
official message saying so. Why do we have the reputation of being so
secure?

>Most people(not just DD) take the defaults, the easy way out.  These numbers
>will increase when the default is to sign.

Currently, it is not even an option to sign. Which is a severe
degradation compared to last week's state of affairs.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: dpkg-sig support wanted?

[Marc Haber]

On Wed, 23 Nov 2005 12:58:12 -0500, Erinn Clark
<[EMAIL PROTECTED]> wrote:
>* Marc Haber <[EMAIL PROTECTED]> [2005:11:23 18:40 +0100]: 
>> On Wed, 23 Nov 2005 17:34:41 +0100, Jeroen van Wolffelaar
>> >Just to provide some statistics about dpkg-sig usage, as I got curious
>> >about it too:
>> >
>> >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].
>> 
>> So, most of the DD's do not care about security at all. Why does
>> Debian have a reputation of being so secure?
>
>Yet just today you filed a bug (#340403) for documentation to be
>included in the package since you were unable to explain dpkg-sig's
>strengths.

The requested documentation is available online, and I have had the
opportunity to talk to dpkg-sig's authors and independent security
people about its advantages.

> How is it possible for you to claim something is more secure
>when you don't understand it well enough to say how it's different?

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.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: dpkg-sig support wanted?

[Matt Zimmerman]

On Wed, Nov 23, 2005 at 09:18:40PM +0100, Goswin von Brederlow wrote:
> Use 2: I have this Ubuntu CD and want to know which debs are from
>debian and which got recompiled
> 
>   Look for all debs that have a deb signature of the debian archive
>   (to be added to dinstall at some point).

I know this is a contrived use case, but Ubuntu doesn't use any .debs from
Debian.

-- 
 - mdz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Marc 'HE' Brockschmidt]

Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes:
> On Tue, Nov 22, 2005 at 04:50:02PM +0100, Marc 'HE' Brockschmidt wrote:
>> As I'm responsible for most of dpkg-sig's code (and planned to do some
>> more work in the next two months) I'd like to know if anyone cares about
>> using these binary signatures or if I can invest my time into something
>> that's a bit more satisfying (== non-Debian stuff). As the ftp-masters
>> and the dpkg maintainers seem to have no interest in the whole thing,
>> I'm beginning to doubt that it's sensible to work on dpkg-sig.
> Just to provide some statistics about dpkg-sig usage, as I got curious
> about it too:
>
> In the archive, 525 out of 283283 .deb's are dpkg-sig'd (0.19%).

Of these 283283 debs, only ~1/9 (1 of 11 archs - packages that are
arch: all, that's only an assumption, correct me if i'm wrong) are
directly uploaded by developers. About 1/4 of the pool should be woody
packages (which was released before dpkg-sig). So we get 283283 * 1/9 *
3/4, which gives us about 23606 packages, which means that 525 are about
2.25%. Regarding the fact that dpkg-sig is not actively advertised
because support in dak and dpkg is still missing, that's not *too* bad.

Marc
-- 
Fachbegriffe der Informatik - Einfach erklärt
25: Multithreaded
   Wir mußten ein Flußdiagramm malen, um es zu debuggen. (Kristian Köhntopp)


pgp7Gj4faAr2l.pgp
Description: PGP signature

Re: dpkg-sig support wanted?

[John Hasler]

I wrote:
> 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 infrastructure or by
> policy.

Marc Haber writes:
> dpkg-sig is harly "hard to use". 

Please re-read what I wrote.
-- 
John Hasler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Stefano Zacchiroli]

On Tue, Nov 22, 2005 at 04:50:02PM +0100, Marc 'HE' Brockschmidt wrote:
> I'd like to know if anyone cares about using these binary signatures

Before your mail I was completely unaware of the existence of dpkg-sig.
Now that I know it, I care about it and would like to start uploading my
packages dpkg-sig-ed (being it possible!).

I hope the current setting will be fixed soon and I will fill a
whishlist bugreport against debuild to support dpkg-sig side by side
with debuild.

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Alexander Schmehl]

* John Hasler <[EMAIL PROTECTED]> [051123 19:11]:
> > 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 infrastructure or by policy.

... or not even know about them.  I haven't heard about HE mentioned
them.


Yours sincerely,
  Alexander

-- 
http://learn.to/quote/
http://www.catb.org/~esr/faqs/smart-questions.html


signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Matthew Garrett]

Peter Samuelson <[EMAIL PROTECTED]> wrote:
>   [Goswin von Brederlow]
>> > Use 2: I have this Ubuntu CD and want to know which debs are from
>> >debian and which got recompiled
>> >=20
>> >   Look for all debs that have a deb signature of the debian archive
>> >   (to be added to dinstall at some point).
> 
> [Matthew Garrett]
>> The answer is "all of them", so this one's not very compelling.

[Someone with a horrid, horrid quoting style]
 
> What?  All Ubuntu .deb files went through ftp-master.debian.org at some
> point?  I know you can't actually mean that.  Hmmm, perhaps you meant
> "none of them"?  If so, that's an Ubuntu-specific answer, because even
> if Ubuntu recompiles all packages, many Debian derivative distributions
> do not.

I was unclear. All of them are recompiled.
 
-- 
Matthew Garrett | [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Goswin von Brederlow]

Matt Zimmerman <[EMAIL PROTECTED]> writes:

> On Wed, Nov 23, 2005 at 09:18:40PM +0100, Goswin von Brederlow wrote:
>> Use 2: I have this Ubuntu CD and want to know which debs are from
>>debian and which got recompiled
>> 
>>   Look for all debs that have a deb signature of the debian archive
>>   (to be added to dinstall at some point).
>
> I know this is a contrived use case, but Ubuntu doesn't use any .debs from
> Debian.

One could prove that. :) There are tons of debian spin offs out there
and a lot will use Debians debs, esspecially CDD disks. So I still
stand by that use.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Goswin von Brederlow]

Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> writes:

> Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes:
>> On Tue, Nov 22, 2005 at 04:50:02PM +0100, Marc 'HE' Brockschmidt wrote:
>>> As I'm responsible for most of dpkg-sig's code (and planned to do some
>>> more work in the next two months) I'd like to know if anyone cares about
>>> using these binary signatures or if I can invest my time into something
>>> that's a bit more satisfying (== non-Debian stuff). As the ftp-masters
>>> and the dpkg maintainers seem to have no interest in the whole thing,
>>> I'm beginning to doubt that it's sensible to work on dpkg-sig.
>> Just to provide some statistics about dpkg-sig usage, as I got curious
>> about it too:
>>
>> In the archive, 525 out of 283283 .deb's are dpkg-sig'd (0.19%).
>
> Of these 283283 debs, only ~1/9 (1 of 11 archs - packages that are
> arch: all, that's only an assumption, correct me if i'm wrong) are
> directly uploaded by developers. About 1/4 of the pool should be woody
> packages (which was released before dpkg-sig). So we get 283283 * 1/9 *
> 3/4, which gives us about 23606 packages, which means that 525 are about
> 2.25%. Regarding the fact that dpkg-sig is not actively advertised
> because support in dak and dpkg is still missing, that's not *too* bad.
>
> Marc

Subtract all sarge debs as signed debs were unwanted for that in fear
of some unknown breakage. Further subtract all packages without upload
since sarge.

Gosh, the percentage keeps on rising. :)

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Goswin von Brederlow]

Stefano Zacchiroli <[EMAIL PROTECTED]> writes:

> On Tue, Nov 22, 2005 at 04:50:02PM +0100, Marc 'HE' Brockschmidt wrote:
>> I'd like to know if anyone cares about using these binary signatures
>
> Before your mail I was completely unaware of the existence of dpkg-sig.
> Now that I know it, I care about it and would like to start uploading my
> packages dpkg-sig-ed (being it possible!).
>
> I hope the current setting will be fixed soon and I will fill a
> whishlist bugreport against debuild to support dpkg-sig side by side
> with debuild.
>
> Cheers.

Please file that against debsign which debuild uses.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Matthew Palmer]

On Thu, Nov 24, 2005 at 02:08:17AM +1000, Anthony Towns wrote:
> On Wed, Nov 23, 2005 at 11:33:47AM +0100, Florian Weimer wrote:
> > * Marc Brockschmidt:
> > > Today (or last night, whatever), the dak installation on ftp-master was
> > > changed to not accept packages that include more than 3 parts, which are
> > > usually the binary version and the compressed control and data
> > > tarballs. This means that signed binary packages are rejected.
> > This is a pity.  I think dpkg-sig is an important step into the right
> > direction: providing more assurances about package integrity to our
> > users.
> 
> 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.

Are you, perchance, interpreting "user" in Florian's message a little too
strictly?  I consider myself a user of Debian, as well as a contributor, and
I can see a couple of uses for signed binary packages for my own purposes
(as well as uses for Debian itself).

Maybe I'm raising a too-long-ago-for-my-recollection flamewar, but I can
think of the following scenarios (not all of them strictly-Debian, though). 
I'd be interested in explanations (or pointers to previous discussions)
discrediting them, so I can be properly enlightened.

1) A signature added by the "originator" of a particular binary package (the
buildds, typically, within Debian) could provide some identification of the
true origin of a binary package.  If a buildd were to be deemed to be
compromised, all packages signed with that buildd's key could be turfed and
rebuilt.  (Note that I'm not suggesting using buildd keys as a "this package
is OK for the archive" check, see my comments below).

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 together custom CDs or package repos.

3) I can verify the provenance of a particular package in my own custom
repos at any time (did that come from Debian?  Did someone build it
internally?  What's going on?) I can kinda-sorta do that if I manually sign
each binary package I download & verify against the Packages->Release chain
with a special "came from Debian" key, and I can verify the source of the
source (heh) package via the dsc signature, but having a complete "chain of
custody" on a binary package seems like a "nice" thing to have.

Maybe that's the snake-oil you speak of, aj -- it gives me the warm fuzzies
to be able to look at a long list of signatures and say "hmm, that looks
secure" when it shouldn't making me anywhere near as fuzzy.

At the very least, though, I can't find a hole which makes binary package
signatures, done properly, any less secure than per-archive signing.  Is your
objection to binary-package signing that it is "no better" than archive
signing, or that it is actively *worse* than per-archive signing (again, if
both are done "properly", whatever we may define that to mean).

One scenario, which initially seems compelling, but which I've since
rejected, is that of "offline signing" of binary packages -- the idea that
the archive can be authenticated via signatures applied to packages before
they hit the archive.  The benefit suggested there is that offline signing
is more secure than leaving the Release.gpg private key somewhere it can
theoretically be stolen and used to sign bogus release files.  The problem
is that, in general, no automatic signing key is any more secure than any
other.  In addition, if (for eg) every buildd had it's own automatic key,
and that was sufficient for admission to the archive and for checking
archive integrity, that you've got less security because there's N keys,
spread across a range of machines, any of which can do the job of letting a
package into the archive.

- Matt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Marc 'HE' Brockschmidt]

Stefano Zacchiroli <[EMAIL PROTECTED]> writes:
[...]
> 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.

Marc
-- 
BOFH #105:#247824
UPS interrupted the server's power


pgpEc4Y7SoQjs.pgp
Description: PGP signature

Re: dpkg-sig support wanted?

[Steve Langasek]

On Wed, Nov 23, 2005 at 10:52:52PM +0100, Marc Haber wrote:
> On Wed, 23 Nov 2005 12:09:34 -0600 (CST), Adam Heath
> <[EMAIL PROTECTED]> wrote:
> >There's been no push.  No default.  No message saying that it's acceptable 
> >and
> >wanted to sign debs.

> So Debian doesn't care about security. If we did, we would have an
> official message saying so. Why do we have the reputation of being so
> secure?

It's an elaborate hoax we put together in order to see how you would react
when you found out it wasn't true.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Thiemo Seufer]

Marc Haber wrote:
[snip]
> > How is it possible for you to claim something is more secure
> >when you don't understand it well enough to say how it's different?
> 
> 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.


Thiemo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Brian May]

> "Marc" == Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> writes:

Marc> Brian May <[EMAIL PROTECTED]> writes:
>>> I've never seen dpkg-sig mentioned before, only debsigs,
>>> so I'm not familiar with the tool itself, but the concept
>>> is one that needs a lot more exposure.
>> I would speculate debsigs got a name change to dpkg-sig. Can somebody
>> confirm or deny?

Marc> No. dpkg-sig is a completly independent application (though
Marc> some ideas were taken from debsigs)

So, can I conclude we should use dpkg-sig and not debsigs?

The reason I haven't uploaded my packages using something like this
is:

* last time I tried, it got rejected, I didn't know the situation has
  changed.

* confusion over which system to use.

* Not integrated with dpkg-buildpackage, debsign, autobuilders, or dak
  yet.
-- 
Brian May <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Anthony Towns]

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 track the path it
> made through the system, and who changed it.  

That's what the .changes file is for.

> > > something that provides DD-to-user package signatures at least in some
> > > cases is very desirable indeed.
> > debian-devel-changes provides this.
> Not in a very useable form, and only for Debian packages uploaded to the
> official Debian archive.  This is hardly good enough.

Uh, packages not uploaded to the official Debian archive can do whatever
they want.

Cheers,
aj



signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Anthony Towns]

On Thu, Nov 24, 2005 at 12:38:37AM +0100, Goswin von Brederlow wrote:
> > I know this is a contrived use case, but Ubuntu doesn't use any .debs from
> > Debian.
> One could prove that. :) 

No, one couldn't -- the signatures could just be removed from the debs,
no recompilation needed.

Cheers,
aj



signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Anthony Towns]

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 together custom CDs or package repos.

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.

> 3) I can verify the provenance of a particular package in my own custom
> repos at any time (did that come from Debian?  Did someone build it
> internally?  What's going on?) I can kinda-sorta do that if I manually sign
> each binary package I download & verify against the Packages->Release chain
> with a special "came from Debian" key, and I can verify the source of the
> source (heh) package via the dsc signature, but having a complete "chain of
> custody" on a binary package seems like a "nice" thing to have.

Sure; but why do that inside the .deb? You can verify a detached signature
just as easily as an inline one (gpgv sig file // gpgv file), and you
can verify a signature of a hash just as easily as a signature of a file.
If you're worried you might lose the detached, signed information, either
keep it with the data it's authenticating (pool/main/f/foo/foo.origin,
eg), or keep good backups, or both.

> At the very least, though, I can't find a hole which makes binary package
> signatures, done properly, any less secure than per-archive signing.

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.

> Is your
> objection to binary-package signing that it is "no better" than archive
> signing, or that it is actively *worse* than per-archive signing (again, if
> both are done "properly", whatever we may define that to mean).

My objection is that it's *useless* for *Debian*. Debian has too many
sources for packages for key management to be plausible, and keeps
packages unchanged over too long a period for the keys to be guaranteed
secure for the lifetime of a package. Additionally, packages can be
authenticated both via Packages.gz files and .changes files, which
already exist and are usable.

> One scenario, which initially seems compelling, but which I've since
> rejected, is that of "offline signing" of binary packages -- the idea that
> the archive can be authenticated via signatures applied to packages before
> they hit the archive.

This is what .changes files are for, and it's useful both for recovering
from compromises and in a "cvs blame" sort of sense. Note that they also
give more information than a simple signature on the .deb.

Hrm, I see queue/done (which contains .changes files going back to the
dark ages) isn't even being mirrored to merkel properly at the moment.
That's not so constructive.

Cheers,
aj



signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Anthony Towns]

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
>   signatures.

Find some don't pass because they were signed with keys that have been
removed from the keyring.

> Use 2: I have this Ubuntu CD and want to know which debs are from
>debian and which got recompiled
>   Look for all debs that have a deb signature of the debian archive
>   (to be added to dinstall at some point).

Never to be added, because it would change the .deb from that which was
originally uploaded, for no benefit.

> Use 3: The debian servers were compromised and the security team takes
>too long to check the archive for my taste
>   Being a normal user I obviously have no mail archive of all the
>   old changes files laying around so that road is closed. But everyone
>   has a Debian stable CD with keyring. See Use 1.

And see why it doesn't work. Not to mention keys added since stable
released, and packages uploaded by those maintainers.

More than just keys removed from the keyring, there's the issue of keys
being compromised -- it's not even unknown for developers to post secret
keys to mailing lists -- the issue that a package that's once been in the
archive may well by now have known security holes (which is why we have
security.debian.org after all), and that this is entirely moot anyway
since the vast majority of packages can't be verified by dpkg-sig.

> > buildd.debian.org gives full logs, to developers or users.
> While the log contains the md5sum of each build deb it does not
> contain any signature against tampering. 

No, that's what the signed .changes file is for.

> Tampered debs can be uploaded by sending a fake mail to the admin and
> filtering out his responce.  A deb signature of the buildd and a
> subsequent dak check would prevent this.

So would having the buildd sign the mails to the buildd admin, which would
have the benefit of not giving a couple of dozen completely untrustworthy
keys special access to the archive. (AIUI, signed mails to the admin are
on the TODO list; at present buildds don't have keys of their own at all)

> >> something that provides DD-to-user package signatures at least in some
> >> cases is very desirable indeed.
> > debian-devel-changes provides this.
> That covers only the sourcefull uploads and the arch specific -changes
> lists are not archived and therefore useless for non constant
> monitoring.

Far easier to fix that, than retrofit 150G of debs to a flawed and
redundant scheme like this.

Cheers,
aj



signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Matthew Palmer]

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 snake oil, at least in so far
> > A signed deb has a seal of procedence and allows one to track the path it
> > made through the system, and who changed it.  
> 
> That's what the .changes file is for.

Only possible if the .changes file is still accessable, and going through
the d-d-c archives isn't exactly convenient.

On that score, the description for d-d-c says that it includes buildd logs,
but a quick scroll through doesn't appear to find any.  Are they sent
somewhere else now, or am I just going blind?  Certainly, if we're going to
be verifying binary packages from the .changes files, we need to have all of
the buildd .changes files available in an archive *somewhere*.

- Matt


signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Matthew Palmer]

On Thu, Nov 24, 2005 at 12:30:37PM +1000, Anthony Towns wrote:
> On Thu, Nov 24, 2005 at 09:09:21AM +1100, Matthew Palmer wrote:
> > 3) I can verify the provenance of a particular package in my own custom
> > repos at any time (did that come from Debian?  Did someone build it
> > internally?  What's going on?) I can kinda-sorta do that if I manually sign
> > each binary package I download & verify against the Packages->Release chain
> > with a special "came from Debian" key, and I can verify the source of the
> > source (heh) package via the dsc signature, but having a complete "chain of
> > custody" on a binary package seems like a "nice" thing to have.
> 
> Sure; but why do that inside the .deb? You can verify a detached signature
> just as easily as an inline one (gpgv sig file // gpgv file), and you
> can verify a signature of a hash just as easily as a signature of a file.
> If you're worried you might lose the detached, signed information, either
> keep it with the data it's authenticating (pool/main/f/foo/foo.origin,
> eg), or keep good backups, or both.

Then there's the opposite argument about "why not do that inside the .deb?". 
On the one hand, if I copy a detached-signed .deb around, I need to remember
to copy the .origin file around with it.  Conversely, if I use in-file sigs,
I can no longer rely on the md5sum of the .deb as originally provided to
verify original provenance.

I think the final judgment in this issue is going to come down to personal
taste and needs more than anything else.

> > At the very least, though, I can't find a hole which makes binary package
> > signatures, done properly, any less secure than per-archive signing.
> 
> 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.

That's a good point.  However, what damage can be done with a bodgy Packages
file, if only well-signed .debs are actually accepted for installation on
the system?  The only thing that comes to mind is wasting some time and
bandwidth on downloading dodgy debs (or their equally-dodgy dependencies),
but if the system checks the signatures before installing anything, can
anything actually be damaged?

> > Is your
> > objection to binary-package signing that it is "no better" than archive
> > signing, or that it is actively *worse* than per-archive signing (again, if
> > both are done "properly", whatever we may define that to mean).
> 
> My objection is that it's *useless* for *Debian*. Debian has too many
> sources for packages for key management to be plausible, and keeps
> packages unchanged over too long a period for the keys to be guaranteed
> secure for the lifetime of a package. Additionally, packages can be
> authenticated both via Packages.gz files and .changes files, which
> already exist and are usable.

Don't the same arguments about key longevity apply to checking the
signatures on .changes files, too?

> > One scenario, which initially seems compelling, but which I've since
> > rejected, is that of "offline signing" of binary packages -- the idea that
> > the archive can be authenticated via signatures applied to packages before
> > they hit the archive.
> 
> This is what .changes files are for, and it's useful both for recovering
> from compromises and in a "cvs blame" sort of sense. Note that they also
> give more information than a simple signature on the .deb.
> 
> Hrm, I see queue/done (which contains .changes files going back to the
> dark ages) isn't even being mirrored to merkel properly at the moment.
> That's not so constructive.

Is there a publically accessable form of queue/done somewhere that people
can download the .changes files from?  That would be quite handy for people
to use to verify binary packages (and would be a darn sight easier to use
than trolling d-d-c archives).

- Matt

Re: dpkg-sig support wanted?

[Anthony Towns]

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. 

Whenever anyone asks "how do you manage the keys", the answer is usually
"automatically sign by dinstall" which means the deb is modified after it
leaves the builders system (invalidating existing authentication methods)
and usually means changing the deb after its entered the archive (for
signatures identifying packages released as part of sarge / etch, or in
the case where an old key expires).

> I think the final judgment in this issue is going to come down to personal
> taste and needs more than anything else.

That's fine for personal repositories, it's not sufficient for Debian's
archive.

> > > At the very least, though, I can't find a hole which makes binary package
> > > signatures, done properly, any less secure than per-archive signing.
> > 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.
> That's a good point.  However, what damage can be done with a bodgy Packages
> file, if only well-signed .debs are actually accepted for installation on
> the system?  

Add a "Depends: some-random-package" that you know has a security hole
to dpkg's entry in the Packages and it'll be automatically installed by
apt. Add a "Conflicts: dpkg" to some package's entry and it'll never be
installed by apt or aptitude. You can possibly be trickier by pointing
apt at a completely different file too, so that the user thinks they're
installing foo, but end up with bar instead only noticing if they see
dpkg say "Unpacking bar (from .../foo_*.deb)". IIRC, it's tricky to make
that actually work.

> The only thing that comes to mind is wasting some time and
> bandwidth on downloading dodgy debs (or their equally-dodgy dependencies),
> but if the system checks the signatures before installing anything, can
> anything actually be damaged?

There are plenty of packages signed by developers, or that have been
included in the archive, that have exploitable security issues.

> > My objection is that it's *useless* for *Debian*. Debian has too many
> > sources for packages for key management to be plausible, and keeps
> > packages unchanged over too long a period for the keys to be guaranteed
> > secure for the lifetime of a package. Additionally, packages can be
> > authenticated both via Packages.gz files and .changes files, which
> > already exist and are usable.
> Don't the same arguments about key longevity apply to checking the
> signatures on .changes files, too?

Sure, that's why we don't encourage users to worry about them.

The advantage is there's no great difficulty to providing new detached
certificates with new signatures, if the need arises. The debs only need
to be changed if they're actual content needs to change. (Which is also
an advantage for users, who correspondingly don't have to worry about
redownloading them)

> > Hrm, I see queue/done (which contains .changes files going back to the
> > dark ages) isn't even being mirrored to merkel properly at the moment.
> > That's not so constructive.
> Is there a publically accessable form of queue/done somewhere that people
> can download the .changes files from?  

No, there isn't anything, apparently the mirroring to merkel got disabled
due to the inode usage / rsync time. There's some 700k odd changes
files. I think the theory is they'll start getting regularly tar.bz2'ed
up and made available with an index file.

> That would be quite handy for people
> to use to verify binary packages (and would be a darn sight easier to use
> than trolling d-d-c archives).

No lie.

Cheers,
aj


signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Marc Haber]

On Thu, 24 Nov 2005 11:54:33 +1000, Anthony Towns
 wrote:
>On Wed, Nov 23, 2005 at 04:37:05PM -0200, Henrique de Moraes Holschuh wrote:
>> Not in a very useable form, and only for Debian packages uploaded to the
>> official Debian archive.  This is hardly good enough.
>
>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.
Allowing things like these is what makes it possible for some people
to work for Debian during their paid time.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: dpkg-sig support wanted?

[Matthew Palmer]

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 than anything else.
> 
> That's fine for personal repositories, it's not sufficient for Debian's
> archive.

Well, I think that personal taste is sufficient for Debian's archive, and it
seems obvious that Those In The Know have decided that they prefer one taste
over another.  

> > > > At the very least, though, I can't find a hole which makes binary 
> > > > package
> > > > signatures, done properly, any less secure than per-archive signing.
> > > 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.
> > That's a good point.  However, what damage can be done with a bodgy Packages
> > file, if only well-signed .debs are actually accepted for installation on
> > the system?  
> 
> Add a "Depends: some-random-package" that you know has a security hole
> to dpkg's entry in the Packages and it'll be automatically installed by
> apt.

You're a lot more devious than I am, AJ, as I'd never considered these
possibilities.

> > > Hrm, I see queue/done (which contains .changes files going back to the
> > > dark ages) isn't even being mirrored to merkel properly at the moment.
> > > That's not so constructive.
> > Is there a publically accessable form of queue/done somewhere that people
> > can download the .changes files from?  
> 
> No, there isn't anything, apparently the mirroring to merkel got disabled
> due to the inode usage / rsync time. There's some 700k odd changes
> files.

Ouch.  rsync must be *loving* those.

- Matt


signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Stefano Zacchiroli]

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 post.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Roger Leigh]

-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 infrastructure or by policy.

ACK.  I certainly care about security, and I'll sign my packages just
as soon as debsign supports it.


Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ 

iD8DBQFDhZtKVcFcaSW/uEgRAp4CAJ93sOae+cyRL9KsTgrIYkme1vHjOwCfXZ4N
zmom+bKRm2tMU16IklDxSNk=
=seoz
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Marc Haber]

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 supported by the infrastructure or by policy.
>
>ACK.  I certainly care about security, and I'll sign my packages just
>as soon as debsign supports it.

So you wouldn't use dpkg-sig even if it were still supported by the
archive?

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: dpkg-sig support wanted?

[Frank Küster]

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 believe them
>>> to be hard to use and not supported by the infrastructure or by policy.
>>
>>ACK.  I certainly care about security, and I'll sign my packages just
>>as soon as debsign supports it.
>
> So you wouldn't use dpkg-sig even if it were still supported by the
> archive?

I think these are bogus questions.  I am a complete non-expert in these
security things.  I am sure that if the project comes to the conclusion
that signing debs is a good thing, more people will do it irrespective
of how convenient the procedure is in the beginning.  If it finds its
way into the Developer's Reference, even more will use it (and start
integrating it into debsign or whatever).  To me, it's not a question of
whether it's easy to use, but rather whether I can be convinced that it
is worth it.

So far, I could not draw any conclusion from this discussion - both the
counter and the pro arguments contain some truth, and uneducated as I am
I cannot judge at the moment.

However, if there was no technical reason to reject signed binary
packages, it seems to me as if making that change to DAK is an abuse of
ftpmaster's powers:  This is a design decision, and it should be made
after thorough public discussion, either by finding a consensus or by
using our constitutional means of making a decision.  Changes should not
be made in advance, except if there is an unrelated technical reason (I
don't know whether this is the case).

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: dpkg-sig support wanted?

[Wouter Verhelst]

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 snake oil, at least in so far
> > > A signed deb has a seal of procedence and allows one to track the path it
> > > made through the system, and who changed it.  
> > 
> > That's what the .changes file is for.
> 
> Only possible if the .changes file is still accessable, and going through
> the d-d-c archives isn't exactly convenient.
> 
> 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 logs, and
AFAIK, there are no plans to that effect, either.

-- 
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Adam D. Barratt]

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 logs, and
> AFAIK, there are no plans to that effect, either.

It doesn't say that.

It says:

"Notices about uploaded packages for the unstable distribution, from
developers, buildds and katie, the archive sentinel."

i.e. the only e-mails from buildds involved are "notices about uploaded
packages", not logs.

Adam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Matthew Palmer]

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 logs,
> >
> > Then that description is wrong. It never did include buildd logs, and
> > AFAIK, there are no plans to that effect, either.
> 
> It doesn't say that.
> 
> It says:
> 
> "Notices about uploaded packages for the unstable distribution, from
> developers, buildds and katie, the archive sentinel."
> 
> i.e. the only e-mails from buildds involved are "notices about uploaded
> packages", not logs.

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 supposed to go to d-d-c, and if so, are they there and
I'm just not seeing them in the list archive?

- Matt


signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Adeodato Simó]

* 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 supposed to go to d-d-c, and if so, are they there and
> I'm just not seeing them in the list archive?

  They go to the respective debian-devel-$ARCH-changes list, none of
  which is archived AIUI.

  Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
You cannot achieve the impossible without attempting the absurd.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Henrique de Moraes Holschuh]

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 track the path it
> > made through the system, and who changed it.  
> 
> That's what the .changes file is for.

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.

Still, .changes file do not carry all the information in-deb sigs do
(although they could, if we sign the .changes files more than once -- but
changes are DAK will croak on that too).  They're not stored along with the
.debs anywhere (we could change that too, I suppose... but I doubt one extra
file per source in the archive will be welcome).  They are *far* from being
as simple to handle as in-deb signatures.  

Not to mention that doing the inverse path (from .deb to .changes) is far
more complicated than using in-deb sigs, and is only possible in fact if you
either always respect some sort of naming convention to go from source
package to .changes (and this *IS* a kludge), or if you read all .change
files hunting for the file you want in the MD5s.

> Uh, packages not uploaded to the official Debian archive can do whatever
> they want.

Sure. But I for one won't be building all debs twice, and many others won't
either.  And proper support for in-deb signatures means added functionality
in a lot of other utilities that won't happen if Debian doesn't use in-deb
signatures, etc.

So, it makes a damn big difference if the Debian archive accepts signed debs
or not.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Henrique de Moraes Holschuh]

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 point about "you can no longer just use md5sum" is useless (you
need gpg, other "special" tools won't make it any more difficult, especially
since they are gzip and ar), the point about not changing the .deb after
upload is a very good one.  In fact, the only good point against in-deb
signatures I've seen so far.

> Sure; but why do that inside the .deb? You can verify a detached signature
> just as easily as an inline one (gpgv sig file // gpgv file), and you

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), and also that the .changes file will be stored in the
archives along with the .debs, and that .debs with wrong/incomplete/missing
Source: fields will be rejected (such as all automated bin-NMUed .debs made
until about a week ago, or any made by a maintainer right now), and that the
path to go from the Source:-field to the .origin/.changes file name is set
in stone...  then yes, detached signatures would do it.

> My objection is that it's *useless* for *Debian*. Debian has too many
> sources for packages for key management to be plausible, and keeps

This applies to .changes files too, with the aggravating addition that those
are a bitch to find right now.

> authenticated both via Packages.gz files and .changes files, which
> already exist and are usable.

ONLY if we change the way .changes files are stored. It would be best to
have them stored in the archive itself along the .debs, really, if we're
going to use them for anything other than initial acceptance through DAK.

However, integrating this on the tools will be far more difficult than an
in-deb signature (still doable, of course), where dpkg would simply refuse
per user-set policy any non-signed deb or any deb without a specific
signature...

> This is what .changes files are for, and it's useful both for recovering
> from compromises and in a "cvs blame" sort of sense. Note that they also
> give more information than a simple signature on the .deb.

Only if we can sign it multiple times, which is one of the capabilities of
the "simple signature on the .deb" we are talking about.

> Hrm, I see queue/done (which contains .changes files going back to the
> dark ages) isn't even being mirrored to merkel properly at the moment.
> That's not so constructive.

Agreed.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Simon Richter]

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 any signed .deb just because a developer 
signed it, that would be bad(tm).


   Simon


signature.asc
Description: OpenPGP digital signature

Re: dpkg-sig support wanted?

[Florian Weimer]

* 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 signature, but from the procedures
that create it and leave a cryptographically secured audit trail on
the binary package.  The approach chosen by dpkg-sig makes it possible
to add further signatures while the package is propagated through
Debian's infrastructure (unless there are some instances of
compare-by-hash hard-wired into it, but there aren't AFAIK).

Of course, with current state of technology, there can't be a digital
signature that directly says that "installation of this package will
not cause any harm".  But this doesn't mean that we should give up
completely.

>> since May 31.  The diff at
>>  shows
>> that the additional check was *removed*, not *added* more than a week
>> ago.
>
> Yes; CVS was corrupted in May and hadn't been updated 'til the other
> week. http://azure.humbug.org.au/~aj/blog/2005/11/16#2005-11-16-dak

So, just to be clear, revision 1.58 (which has been committed in the
meantime) is equivalent (if not identical) to the production version,
and adding metadata in the way dpkg-sig does is no longer possible?

>> Since there is no way for Debian Developers to review the way Debian
>> packages are created (and it's totally out of question for end users),
>
> buildd.debian.org gives full logs, to developers or users.

But what do you do if there is a discrepancy between the hash in those
logs and the package which is actually in the archive?  I don't know
how common this would be; the hashes on buildd.debian.org are not in a
readily extractable format, it seems.

Oh, and I looked again at the buildd stats after some time.  Good to
see that m68k is not lagging behind as dramatically as it used to.
Debian is not doomed after all. 8-)

>> something that provides DD-to-user package signatures at least in some
>> cases is very desirable indeed.
>
> debian-devel-changes provides this.

AFAIK, binary NMus aren't announced on debian-devel-changes.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Goswin von Brederlow]

Anthony Towns  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 together custom CDs or package repos.
>
> You can already use release signatures for this. Further, changing the

Only if you have a release signature corresponding to every deb and
the Packages files where that deb was in. If you collect debs over any
amount of time that would become a huge archive.

> 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 far nothing is changing debs after upload. The deb signatures
so far are all done prior to uploading and even changes file
generation. Only a dinstall signature would change that, making the
changes file less easy to verify while keeping everything else the
same.

>> 3) I can verify the provenance of a particular package in my own custom
>> repos at any time (did that come from Debian?  Did someone build it
>> internally?  What's going on?) I can kinda-sorta do that if I manually sign
>> each binary package I download & verify against the Packages->Release chain
>> with a special "came from Debian" key, and I can verify the source of the
>> source (heh) package via the dsc signature, but having a complete "chain of
>> custody" on a binary package seems like a "nice" thing to have.
>
> Sure; but why do that inside the .deb? You can verify a detached signature
> just as easily as an inline one (gpgv sig file // gpgv file), and you
> can verify a signature of a hash just as easily as a signature of a file.
> If you're worried you might lose the detached, signed information, either
> keep it with the data it's authenticating (pool/main/f/foo/foo.origin,
> eg), or keep good backups, or both.

I've requested that the changes files be kept along with the debs in
pool several times. It aparently isn't going to happen. Also a
detached signature needs more space since it uses another inode and a
full block on the filesystem instead of just the few bytes inside the
deb.

And yes, I am worried about loosing the detached signatures. Why risk
it if we have a perfect mechanism without it?

>> At the very least, though, I can't find a hole which makes binary package
>> signatures, done properly, any less secure than per-archive signing.
>
> 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 of a package to appear in the
Packages file by compromising it. You can't subvert a package itself.
But you can already ship yesterdays Release.gpg, Release and Packages
file to a user and thereby prevent any updates.

On the other hand, without package signatures ftp-master adds a
vulnerability. You can hack into it, replace debs, recreate the
Packages, Release and Release.gpg file and thereby infect users. With
signed debs that could still be detected by every user in apt-get.

It is not that I don't trust ftp-master but that I don't even have to
trust it.

>> Is your
>> objection to binary-package signing that it is "no better" than archive
>> signing, or that it is actively *worse* than per-archive signing (again, if
>> both are done "properly", whatever we may define that to mean).
>
> My objection is that it's *useless* for *Debian*. Debian has too many
> sources for packages for key management to be plausible, and keeps
> packages unchanged over too long a period for the keys to be guaranteed
> secure for the lifetime of a package. Additionally, packages can be
> authenticated both via Packages.gz files and .changes files, which
> already exist and are usable.

Changes files are not publicly accessible on demand so they are not
practical for any authentication. And even if you have a changes file
at hand by chance its signature has exactly the same security as
debsig has. It is as secure as the DDs key. The major difference is
the accessibility.

And Packages.gz has a 24h lifetime at worst. It is only a temporary
means to validate a deb.

So both methods are, to put it in your words, *useless* for *users*.
Please have a bit of an open mind and don't just think about what the
archive needs.

>> One scenario, which initially seems compelling, but which I've since
>> rejected, is that of "offline signing" of binary packages -- the idea that
>> the archive can be authenticated via signatures applied to packages before
>> they hit the archive.
>
> This is what .changes files are for, and it's useful both for recovering
> from compromises and in a "cvs blame" sort of sense. Note that they also
> give more information than a simple signature on the .deb.
>
> Hrm, I see queue/done (which c

Re: dpkg-sig support wanted?

[Goswin von Brederlow]

Anthony Towns  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 have an unwarranted feeling of security? You keep hinting
at debsig being insecure but nothing you have said makes it any
different (security wise) from changes files.

> Whenever anyone asks "how do you manage the keys", the answer is usually
> "automatically sign by dinstall" which means the deb is modified after it
> leaves the builders system (invalidating existing authentication methods)
> and usually means changing the deb after its entered the archive (for
> signatures identifying packages released as part of sarge / etch, or in
> the case where an old key expires).

That is just plain wrong. The only existing debsig signatures are all
done by the builder and/or DD prior to creating the changes file. And
that is all what the initial post in this thread was about.

Having dinstall _also_ sign debs is an option that can be implemented
or not. And it would only invalidate one authentication method: using
a plain md5sum and the changes files. The Packages files md5sum would
naturaly be the md5sum after signing and still work.

Let me repeat this for you: An automatic dinstall signature is just an
option.

...
>> That's a good point.  However, what damage can be done with a bodgy Packages
>> file, if only well-signed .debs are actually accepted for installation on
>> the system?  
>
> Add a "Depends: some-random-package" that you know has a security hole
> to dpkg's entry in the Packages and it'll be automatically installed by
> apt. Add a "Conflicts: dpkg" to some package's entry and it'll never be
> installed by apt or aptitude. You can possibly be trickier by pointing
> apt at a completely different file too, so that the user thinks they're
> installing foo, but end up with bar instead only noticing if they see
> dpkg say "Unpacking bar (from .../foo_*.deb)". IIRC, it's tricky to make
> that actually work.

All you do there is install a trusted package or sabotage installing a
package. An attacker still can't change any package. And all of that
you can do with or without package signatures. If the original package
is buggy too bad. That is what we have security.debian.org for.

Signed debs are not ment to protect the Packages file, we have the
Release file for that. Signed debs are ment to protect the deb itself.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Frank Küster]

Goswin von Brederlow <[EMAIL PROTECTED]> wrote:

> Anthony Towns  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 far nothing is changing debs after upload. The deb signatures
> so far are all done prior to uploading and even changes file
> generation. Only a dinstall signature would change that, making the
> changes file less easy to verify while keeping everything else the
> same.

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 re-ar it?

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: dpkg-sig support wanted?

[Goswin von Brederlow]

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 be changed. If
> the archive were to accept any signed .deb just because a developer
> signed it, that would be bad(tm).
>
> Simon

The only differences between accepting signed debs and signed changes
files are that changes file have some additional infos (like who gets
the ACK mails) and what set of debs go together.

Both features are still needed with signed debs and nobody has any
intention of changing them. The only request so far is to not reject
debs that are also signed themself.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Goswin von Brederlow]

Anthony Towns  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
>>   signatures.
>
> Find some don't pass because they were signed with keys that have been
> removed from the keyring.

Those I remove and refetch from a clean source again. False negatives
are no big deal. 99% of the debs will verify leaving only a
managable amount of wokr behind.

>> Use 2: I have this Ubuntu CD and want to know which debs are from
>>debian and which got recompiled
>>   Look for all debs that have a deb signature of the debian archive
>>   (to be added to dinstall at some point).
>
> Never to be added, because it would change the .deb from that which was
> originally uploaded, for no benefit.

Fair enough.

>> Use 3: The debian servers were compromised and the security team takes
>>too long to check the archive for my taste
>>   Being a normal user I obviously have no mail archive of all the
>>   old changes files laying around so that road is closed. But everyone
>>   has a Debian stable CD with keyring. See Use 1.
>
> And see why it doesn't work. Not to mention keys added since stable
> released, and packages uploaded by those maintainers.
>
> More than just keys removed from the keyring, there's the issue of keys
> being compromised -- it's not even unknown for developers to post secret
> keys to mailing lists -- the issue that a package that's once been in the

Compromised keys are compromised keys. No matter what you use for
authentification they don't change. One has to look for revocation
certificates and remove bad keys from the keyring prio to checking
signatures.

> archive may well by now have known security holes (which is why we have

As for known security holes in packages. They are known. The signature
of a deb only tells me that no new holes were added. And yes, that is
what we have security.debian.org for.

> security.debian.org after all), and that this is entirely moot anyway
> since the vast majority of packages can't be verified by dpkg-sig.

Ah, I see the light.

Signatures are useless because packages have no signatures.
Lightbulbs do not work because without lightbulbs it is dark.
You can't breath air because there is no oxygen in a vacuum.

>> > buildd.debian.org gives full logs, to developers or users.
>> While the log contains the md5sum of each build deb it does not
>> contain any signature against tampering. 
>
> No, that's what the signed .changes file is for.

Which aren't readily available to the public.

>> Tampered debs can be uploaded by sending a fake mail to the admin and
>> filtering out his responce.  A deb signature of the buildd and a
>> subsequent dak check would prevent this.
>
> So would having the buildd sign the mails to the buildd admin, which would
> have the benefit of not giving a couple of dozen completely untrustworthy
> keys special access to the archive. (AIUI, signed mails to the admin are
> on the TODO list; at present buildds don't have keys of their own at all)

Nothing in signed debs gives any keys additional access to the
archive. Checking for a buildd signature would only restrict the
access further from what we have already, not weaken it.

>> >> something that provides DD-to-user package signatures at least in some
>> >> cases is very desirable indeed.
>> > debian-devel-changes provides this.
>> That covers only the sourcefull uploads and the arch specific -changes
>> lists are not archived and therefore useless for non constant
>> monitoring.
>
> Far easier to fix that, than retrofit 150G of debs to a flawed and
> redundant scheme like this.
>
> Cheers,
> aj

Where is there any flaw? You still haven't shown any that changes
files don't also have.

As to redundant. Yes they are redundant to changes files, IF ONLY one
could get a changes file when needed and have multiple signatures in it.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Marc 'HE' Brockschmidt]

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 re-ar it?

You can simply strip off the parts that change the md5sum, without the
unpack/pack cycle. The problem is to know which parts need to be removed.

Marc
-- 
BOFH #335:
the AA battery in the wallclock sends magnetic interference


pgprsAWzGrlFl.pgp
Description: PGP signature

Re: dpkg-sig support wanted?

[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.

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
As scarce as truth is, the supply has always been in excess of the demand.
-- Josh Billings


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Anthony Towns]

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 dpkg-sign's concerned, can't you already do that by building
the package, uploading it to debian, then running dpkg-sign? At worst
you'd have to run dpkg-genchanges again before uploading to your other
suite, afaics.

> Allowing things like these is what makes it possible for some people
> to work for Debian during their paid time.

Cheers,
aj



signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Henrique de Moraes Holschuh]

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 same package for different things.
> 
> As far as dpkg-sign's concerned, can't you already do that by building
> the package, uploading it to debian, then running dpkg-sign? At worst
> you'd have to run dpkg-genchanges again before uploading to your other
> suite, afaics.

You're correct.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Anthony Towns]

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 than anything else.
> > That's fine for personal repositories, it's not sufficient for Debian's
> > archive.
> Well, I think that personal taste is sufficient for Debian's archive, and it
> seems obvious that Those In The Know have decided that they prefer one taste
> over another.  

*sigh* Do you really think that comment was helpful?

> > Add a "Depends: some-random-package" that you know has a security hole
> > to dpkg's entry in the Packages and it'll be automatically installed by
> > apt.
> You're a lot more devious than I am, AJ, as I'd never considered these
> possibilities.

I've had this same conversation a dozen times before...

> > No, there isn't anything, apparently the mirroring to merkel got disabled
> > due to the inode usage / rsync time. There's some 700k odd changes
> > files.
> Ouch.  rsync must be *loving* those.

Well, it's loving them being excluded, yeah...

Developers who'd like to play with making a workable format for .changes
files can play around with changes files separated by month up 'til
2005/04 by poking around in /org/ftp.debian.org/queue/done on merkel;
changes up 'til August are also available unseparated, but you're better
off just ignoring those for experimenting.

Cheers,
aj


signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Anthony Towns]

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, at least in so far
> > > A signed deb has a seal of procedence and allows one to track the path it
> > > made through the system, and who changed it.  
> > That's what the .changes file is for.
> 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.

Sure, and sugar water is okay for quenching your thirst, but it's still
snake oil as far as, say, curing cancer is concerned.

.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 validity.

.changes files aren't aimed at users, they're aimed at the archive --
the fact that they become more complicated to validate over time isn't a
problem, because they're not expected to be validated in the future on a
regular basis.

> Still, .changes file do not carry all the information in-deb sigs do
> (although they could, if we sign the .changes files more than once -- but
> changes are DAK will croak on that too).  

You can have multiple signatures on a .changes file easily -- you
strip the old signature, add a new one, and tar the two (or more) files
up together. Or you use detached signatures of an origianl signed or
unsigned changes file. That has nothing to do with dak or Debian though.

> Not to mention that doing the inverse path (from .deb to .changes) is far
> more complicated than using in-deb sigs, 

*shrug* Grepping through files isn't that difficult. You can use indices
to make it quicker if it matters, but it doesn't.

> > Uh, packages not uploaded to the official Debian archive can do whatever
> > they want.
> Sure. But I for one won't be building all debs twice,

Uh, you add a signature to a .deb after building it. Upload the .deb to
Debian before signing it if you want it both in Debian and in some local
repository that requires signed debs.

> So, it makes a damn big difference if the Debian archive accepts signed debs
> or not.

Cheers,
aj



signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Anthony Towns]

On Thu, Nov 24, 2005 at 07:47:58PM +0100, Goswin von Brederlow wrote:
> Anthony Towns  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
> >>   signatures.
> > Find some don't pass because they were signed with keys that have been
> > removed from the keyring.
> Those I remove and refetch from a clean source again. False negatives
> are no big deal. 99% of the debs will verify leaving only a
> managable amount of wokr behind.

The "clean" source that's signed by the same key that you can't verify?

> >> Use 3: The debian servers were compromised and the security team takes
> >>too long to check the archive for my taste
> >>   Being a normal user I obviously have no mail archive of all the
> >>   old changes files laying around so that road is closed. But everyone
> >>   has a Debian stable CD with keyring. See Use 1.
> > And see why it doesn't work. Not to mention keys added since stable
> > released, and packages uploaded by those maintainers.
> > More than just keys removed from the keyring, there's the issue of keys
> > being compromised -- it's not even unknown for developers to post secret
> > keys to mailing lists -- the issue that a package that's once been in the
> Compromised keys are compromised keys. 

Compromised keys are not, however, compromised debs.

> Ah, I see the light.
> Signatures are useless because packages have no signatures.

That's a transitional problem, yes. In this case it's a severe one;
since there are up to 150GBs worth of .debs. It's a problem that could be
solved if it were worthwhile, but it's not worthwhile since .changes
already do everything deb sigs could do without any transition issues,
and it's not something that can be simply ignored.

Cheers,
aj



signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Anthony Towns]

On Thu, Nov 24, 2005 at 11:13:45AM -0200, Henrique de Moraes Holschuh wrote:
> While the point about "you can no longer just use md5sum" is useless (you
> need gpg, other "special" tools won't make it any more difficult, especially
> since they are gzip and ar), 

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 dpkg
actually use parts of the .deb that haven't been authenticated under the
false conviction that you're actually safe. With "md5sum foo.deb" you
know you've authenticated everything.

(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...)

> 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), 

Huh? Why do you want multiple signatures of a .changes file?

> and also that the .changes file will be stored in the
> archives along with the .debs, 

As it turns out, that's probably not feasible per se -- it likely implies
too much inode usage, and slack space.

> and that .debs with wrong/incomplete/missing
> Source: fields will be rejected (such as all automated bin-NMUed .debs made
> until about a week ago, or any made by a maintainer right now),

Huh? I don't think #62529 is fixed yet. If you think you'll have better
luck at doing so, be my guest. That's not a prerequisite for verifying
packages from changes files though.

> > My objection is that it's *useless* for *Debian*. Debian has too many
> > sources for packages for key management to be plausible, and keeps
> This applies to .changes files too, with the aggravating addition that those
> are a bitch to find right now.

Uh, no, .changes files are not remotely useless for Debian right now.
Where would you get that idea?

> ONLY if we change the way .changes files are stored. It would be best to
> have them stored in the archive itself along the .debs, really, if we're
> going to use them for anything other than initial acceptance through DAK.
> 
> However, integrating this on the tools will be far more difficult than an
> in-deb signature (still doable, of course), 

The tools are the least concern; what's a few dozen lines of code here
and there matter? If you insist every package only be uploaded once, and
do the maximum packages per day, and stop all other development just to
get deb sigs done, it's roughly half a year before that's finished. New
packages, bug fixes, new upstream versions will make it take longer.

> where dpkg would simply refuse
> per user-set policy any non-signed deb or any deb without a specific
> signature...

I'm sorry, but you're back to the snakeoil use for deb sigs. Expecting
a signature by a random Debian developer to mean something is not
reasonable.

Would it help you see the point if I signed a version of dpkg that
installed a suid shell somewhere, and put that up on people.debian.org?
I'm tempted to do something like that anyway to see if the md5sum
exploit can be used to create fire and ice .debs. Without signed debs,
you'll have no reason to trust it, which is exactly right; with signed
debs, you'll have reason to know I built it, but you won't have reason
to know I was never going to upload it to Debian because I was just
experimenting with some possible security vectors. The question is, will
you make the unwarranted assumption that because it's been built by me,
that it's usable my you?

(changes have the advantage that they include the changelog ("Added suid
shell" might stand out) and the suite for it to be uploaded to
("aj-experimental" perhaps), but that only helps if you actually look at
it, rather than just having dpkg check the signature)

> > This is what .changes files are for, and it's useful both for recovering
> > from compromises and in a "cvs blame" sort of sense. Note that they also
> > give more information than a simple signature on the .deb.
> Only if we can sign it multiple times, which is one of the capabilities of
> the "simple signature on the .deb" we are talking about.

The explanation you need is "...which is useful because _". Again, I
can't see any need for multiple signatures for Debian; for non-Debian,
if deb sigs are convenient, use them.

Cheers,
aj


signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Anthony Towns]

On Thu, Nov 24, 2005 at 06:28:04PM +0100, Florian Weimer wrote:
> Of course, with current state of technology, there can't be a digital
> signature that directly says that "installation of this package will
> not cause any harm".  But this doesn't mean that we should give up
> completely.

Mmm. I'd phrase that differently: "with the current state of technology,
there's no way of assuring that "installation of this package will not
cause any harm"". 

Which is fine; we can't assure that yet, so there's no point worrying
about it. We can provide a weaker assurance though, namely "to the
best of our knowledge, installation of this package will not create
any security vulnerabilities", or even "to the best of our knowledge,
this package does not have any release critical bugs".

Those are issues that users are interested in, and digital signatures
provide a reliable way to communicate those assurances to users.

The problem is, we can't make the latter assurance meaningfully at build
time; and more importantly both assurances are time-dependendant --
more information keeps coming to hand, and users will naturally want
the latest possible.  So we didn't know foo was exploitable last week,
big deal -- do we know it's still not exploitable today?

We currently pass on those assurances via the Release-Packages-deb path
on our archive; and expecting users to use apt-get to ensure they've got
a current assurance.

> So, just to be clear, revision 1.58 (which has been committed in the
> meantime) is equivalent (if not identical) to the production version,
> and adding metadata in the way dpkg-sig does is no longer possible?

Yes, jennifer's identical apart from some $Id$ strings. The issue's more
that ar members are checked for correctness than that additional
metadata's specifically disabled. AIUI, some of the hystrionics on
channels I no longer frequent have discouraged folks from doing dpkg-sig
advocates any favours. *shrug*

> >> Since there is no way for Debian Developers to review the way Debian
> >> packages are created (and it's totally out of question for end users),
> > buildd.debian.org gives full logs, to developers or users.
> But what do you do if there is a discrepancy between the hash in those
> logs and the package which is actually in the archive? 

Same thing you do if you find a discrepency between the md5sum in the
Packages file and a .deb -- investigate where the corruption is and
report it?

> I don't know
> how common this would be; the hashes on buildd.debian.org are not in a
> readily extractable format, it seems.

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 deliver .changes for whatever
purpose you've got in mind would be a good idea. (Again though, I don't
see a point to them, beyond reverification of the archive in the event
of an exploit. Of course, maybe that's what you want to do...)

> Oh, and I looked again at the buildd stats after some time.  Good to
> see that m68k is not lagging behind as dramatically as it used to.
> Debian is not doomed after all. 8-)

I find it amusing that all bar arm and m68k are above the 98% barrier
that caused such consternation earlier in the year...

> >> something that provides DD-to-user package signatures at least in some
> >> cases is very desirable indeed.
> > debian-devel-changes provides this.
> AFAIK, binary NMus aren't announced on debian-devel-changes.

As others have pointed out, ddc's for source uploads, binary-only uploads
are on the arch-specific lists. AFAIK binNMUs aren't treated specially
in that respect.

Cheers,
aj



signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Steve Langasek]

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 of a package to appear in the
> Packages file by compromising it. You can't subvert a package itself.
> But you can already ship yesterdays Release.gpg, Release and Packages
> file to a user and thereby prevent any updates.

> On the other hand, without package signatures ftp-master adds a
> vulnerability. You can hack into it, replace debs, recreate the
> Packages, Release and Release.gpg file and thereby infect users. With
> signed debs that could still be detected by every user in apt-get.

Only if every user is in a position to verify signatures from each Debian
developer individually, which is completely unrealistic.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Hamish Moffatt]

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 .debs
not build by Debian developers? Shouldn't sponsors be recompiling
packages from non-DDs before upload?


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Adeodato Simó]

* 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 off the topic, but does this mean the archive contains .debs
> not build by Debian developers? Shouldn't sponsors be recompiling
> packages from non-DDs before upload?

  I was suspicious too, but it was later checked on irc that all keys
  actually belonged to a DD. (One of them was not in public keyservers,
  AIUI, and Jeroen assumed it was not a DD, or something similar.)

  Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
A lie can go round the world before the truth has got its boots on.
-- Terry Pratchett


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Simon Richter]

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 dpkg
actually use parts of the .deb that haven't been authenticated under the
false conviction that you're actually safe. With "md5sum foo.deb" you
know you've authenticated everything.


Which is also a disadvantage in some cases. I could see a case for 
extending .deb files (say, with additional translations for the 
description and templates, thus removing the need for the maintainer to 
reupload new packages when new translations are ready).


I think that it should be fairly easy to implement something that can 
verify parts of .deb files and check whether the authenticated parts 
together form a complete and consistent package on their own.


This thread, however, is not about a technical problem, so I would 
propose a sauna meeting.



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 sure what interesting breakage would occur if one were to 
upload a changes file with multiple signatures.



and also that the .changes file will be stored in the
archives along with the .debs, 



As it turns out, that's probably not feasible per se -- it likely implies
too much inode usage, and slack space.


And is probably pointless. If you don't trust the Debian infrastructure, 
you are free to get the source (which is signed by the maintainer) and 
build the package yourself.



where dpkg would simply refuse
per user-set policy any non-signed deb or any deb without a specific
signature...



I'm sorry, but you're back to the snakeoil use for deb sigs. Expecting
a signature by a random Debian developer to mean something is not
reasonable.


That's why there can be multiple signatures. There would be one from the 
maintainer/buildd, a few from the Debian archive (for example, you could 
add one sig for "officially in Debian unstable", one for "migrated to 
testing" and one for "in a stable release") and if the idea of adding 
description/template translations later on catches on, also some from 
the translators/translation system.


   Simon


signature.asc
Description: OpenPGP digital signature

Re: dpkg-sig support wanted?

[Goswin von Brederlow]

Anthony Towns  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 deliver .changes for whatever
> purpose you've got in mind would be a good idea. (Again though, I don't
> see a point to them, beyond reverification of the archive in the event
> of an exploit. Of course, maybe that's what you want to do...)

We have a perfectly useable and trivial way to deliver the hashes,
which is the intresting part of the changes file for security. It is
the signature in the deb.


For comparison: Why do we have a signature in dsc files? From your
arguments that signature is completly useless since changes files
already provide all that is needed.

We still sign dsc files because it is just that much easier to apt-get
source foo and verify it. And that is a good thing. Why are you so set
in stone against allowing the same for debs?

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Goswin von Brederlow]

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 anything?
>
>> At best you can prevent a newer version of a package to appear in the
>> Packages file by compromising it. You can't subvert a package itself.
>> But you can already ship yesterdays Release.gpg, Release and Packages
>> file to a user and thereby prevent any updates.
>
>> On the other hand, without package signatures ftp-master adds a
>> vulnerability. You can hack into it, replace debs, recreate the
>> Packages, Release and Release.gpg file and thereby infect users. With
>> signed debs that could still be detected by every user in apt-get.
>
> Only if every user is in a position to verify signatures from each Debian
> developer individually, which is completely unrealistic.

Up to a point you can trust the keyring. As much as you can trust any
DD signature. You try to argue that signatures are not absolutely
trustworthy but that is nothing new. Nothing you can do will change
that. What you fail to see (or say) is that all the security Debian
already has is weak in exactly the same way. The difference to signed
debs is the transparency and triviality to check. Even if that check
has to use a 5 hop trust path to some DD you never met.

Also for !i386 !ppc basicaly all packages are autobuild and will be
signed by a handfull of people. You can go and meet them easily
enough.

Further, with signed debs, you could only allow installation of debs
from people you trust and recompile all the rest after a source
audit. If you are that paranoid.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Goswin von Brederlow]

Anthony Towns  writes:

> On Thu, Nov 24, 2005 at 07:47:58PM +0100, Goswin von Brederlow wrote:
>> Anthony Towns  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
>> >>   signatures.
>> > Find some don't pass because they were signed with keys that have been
>> > removed from the keyring.
>> Those I remove and refetch from a clean source again. False negatives
>> are no big deal. 99% of the debs will verify leaving only a
>> managable amount of wokr behind.
>
> The "clean" source that's signed by the same key that you can't verify?

If I can't find any verifiable source then the package can't be
trusted and can be removed till that is changed. Still much better
than having 100% untrustworthy packages.

>> Ah, I see the light.
>> Signatures are useless because packages have no signatures.
>
> That's a transitional problem, yes. In this case it's a severe one;
> since there are up to 150GBs worth of .debs. It's a problem that could be
> solved if it were worthwhile, but it's not worthwhile since .changes
> already do everything deb sigs could do without any transition issues,
> and it's not something that can be simply ignored.
>
> Cheers,
> aj

By the way, this is trivial to work around:
1) archive the Release.gpg, Release and Packages file from today
2) only allow signed debs from now on
>From then on all debs can be verified.


I say the transition can be simply ignored (for now). The problem will
fix itself in due time when signed debs become more popular and
debsign automatically adds them. At some point in the future the
majority of debs will be signed and then a transition can be force by
scheduling a binNMU for any remaining deb.

But first there must be an official "debs may be signed" before anyone
can think about a "debs MUST be signed".

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Goswin von Brederlow]

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 upload a package to
>> > Debian and to be able to use the same package for different things.
>> 
>> As far as dpkg-sign's concerned, can't you already do that by building
>> the package, uploading it to debian, then running dpkg-sign? At worst
>> you'd have to run dpkg-genchanges again before uploading to your other
>> suite, afaics.
>
> 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.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Goswin von Brederlow]

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 sure what interesting breakage would occur if one were to
> upload a changes file with multiple signatures.

It gives a parse error and the DAK rejects the file.

>>>where dpkg would simply refuse
>>>per user-set policy any non-signed deb or any deb without a specific
>>>signature...
>
>> I'm sorry, but you're back to the snakeoil use for deb sigs. Expecting
>> a signature by a random Debian developer to mean something is not
>> reasonable.

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.

> That's why there can be multiple signatures. There would be one from
> the maintainer/buildd, a few from the Debian archive (for example, you
> could add one sig for "officially in Debian unstable", one for
> "migrated to testing" and one for "in a stable release") and if the
> idea of adding description/template translations later on catches on,
> also some from the translators/translation system.

Although that would alter the packages md5sum and even alter a package
while still being in a distribution (the unstable deb would suddenly
gain a signature). It would be a big change to allow this.

> Simon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Matthew Palmer]

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 to be made by a
key which is still trustworthy at the time of verification, which could be
quite some time in the future.  The key which makes a .changes signature, in
contrast, only *needs* to be valid at the time the upload is made -- if it
is later compromised, it's not important, because by that time the archive
signing key hsa taken over the role of integrity verification.

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,
and since the .changes from autobuilt uploads aren't publically available
(apparently d-d-$arch-changes isn't archived, from info previously posted in
this thread) that method of package authentication isn't going to be 100%
reliable anyway.

- Matt


signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Olaf van der Spek]

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 lifetime issue?
Is it a cryptographic issue?

> and since the .changes from autobuilt uploads aren't publically available
> (apparently d-d-$arch-changes isn't archived, from info previously posted in
> this thread) that method of package authentication isn't going to be 100%
> reliable anyway.

Re: dpkg-sig support wanted?

[Goswin von Brederlow]

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 same, actually.  A signature in a .deb needs to be made by a
> key which is still trustworthy at the time of verification, which could be
> quite some time in the future.  The key which makes a .changes signature, in
> contrast, only *needs* to be valid at the time the upload is made -- if it
> is later compromised, it's not important, because by that time the archive
> signing key hsa taken over the role of integrity verification.

And there you have the big misconception.

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 deb on ftp-master.

The chain of trust from the DD to the enduser is broken at that point
when the chnages file disapears into a non public place and the
Release.gpg takes over. Even worse the Release.gpg is signed with an
automatic key which I trust way less than a DDs key.

> 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,
> and since the .changes from autobuilt uploads aren't publically available
> (apparently d-d-$arch-changes isn't archived, from info previously posted in
> this thread) that method of package authentication isn't going to be 100%
> reliable anyway.
>
> - Matt

The key-lifetime issue, as you say, is already there for the changes
files. It also already there for the dsc files. The deb signatures
don't change a thing there.

What they change is the availability of the signature. And that they
change to 100% for every signed deb (and we hope all debs gets igned
at some point).

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Goswin von Brederlow]

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 as in-deb signatures,
>
> What exactly is this key lifetime issue?
> Is it a cryptographic issue?

A key can expire, get stolen / lost or get compromised and
revoced. Once that happens you can't trust any signature made by that
key.

Although one can probably argue that an expired key still has enough
trust to verify old debs. Many people don't set an expiry date anyway.


While this sounds like a big problem lets have some numbers:

Shortly before the sarge release we imported all source packages into
the debian-amd64 DAK and actualy did have the problem with dsc file
signatures. But that was a problem of maybe 20 packages (out of
over 8000).

Overall a miniscule problem. If I can verify all but 20 packages that
realy is a great bonus.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Henrique de Moraes Holschuh]

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?

> Huh? Why do you want multiple signatures of a .changes file?

If I am to do with a .changes file everything I can do with the in-deb
signatures, it needs to support at least nested signatures.

> > and also that the .changes file will be stored in the
> > archives along with the .debs, 
> 
> As it turns out, that's probably not feasible per se -- it likely implies
> too much inode usage, and slack space.

That speaks for in-deb signatures in the usability department.

> > and that .debs with wrong/incomplete/missing
> > Source: fields will be rejected (such as all automated bin-NMUed .debs made
> > until about a week ago, or any made by a maintainer right now),
> 
> Huh? I don't think #62529 is fixed yet. If you think you'll have better
> luck at doing so, be my guest. That's not a prerequisite for verifying
> packages from changes files though.

Well, the email about the new bin-NMU structure implied that it was fixed
for *NMUs done through that structure*.  I very much doubt we can produce
bin NMUs in our systems with the proper Source header without taking very
special steps.

> > > My objection is that it's *useless* for *Debian*. Debian has too many
> > > sources for packages for key management to be plausible, and keeps
> > This applies to .changes files too, with the aggravating addition that those
> > are a bitch to find right now.
> 
> Uh, no, .changes files are not remotely useless for Debian right now.
> Where would you get that idea?

I was refering to "Debian has too many sources for packages for key
management to be plausible".  Duh, obviously .change files are useful for
Debian, DAK needs them.

> The tools are the least concern; what's a few dozen lines of code here
> and there matter? If you insist every package only be uploaded once, and
> do the maximum packages per day, and stop all other development just to
> get deb sigs done, it's roughly half a year before that's finished. New
> packages, bug fixes, new upstream versions will make it take longer.

Who said anything about adding in-deb sigs to the entire archive?

> > where dpkg would simply refuse
> > per user-set policy any non-signed deb or any deb without a specific
> > signature...
> 
> I'm sorry, but you're back to the snakeoil use for deb sigs. Expecting

I see I have to spell it out completely all the time, for you will always
assume you are talking to clueless people who either doesn't know anything
about the issue at hand, or who will be impressed by your over-use of
"snake-oil".

If I want dpkg to always check a signature, it is because it is a signature
I know must be there.  Like an hypothetical signature added by
DAK/dinstall/whatever, or a signature I add to all debs in a specific
repository under my control (and in this case, with a timestamp under my own
control too, which means I can use it).  Doing so with signed release files
is possible, but not always in the same way and under the same conditions,
and it requires a lot of fragile infrastructure which would be less fragile
using in-deb signatures.

> a signature by a random Debian developer to mean something is not
> reasonable.

YOU are the one who is bringing in signatures from j.random developer.
Which, I should add, is all we have in .changes files.  Release files are
something else, though.

> I'm tempted to do something like that anyway to see if the md5sum
> exploit can be used to create fire and ice .debs. Without signed debs,

Make that an exploit that says "kaboom, you're it" but still runs dpkg, and
I will help you with it.

> you'll have no reason to trust it, which is exactly right; with signed
> debs, you'll have reason to know I built it, but you won't have reason
> to know I was never going to upload it to Debian because I was just
> experimenting with some possible security vectors. The question is, will
> you make the unwarranted assumption that because it's been built by me,
> that it's usable my you?

I won't, that's for sure.  I might trust such a deb because it was in a
archive where you place debs for general use or something else like that,
but not because you signed it.

> The explanation you need is "...which is useful because _". Again, I
> can't see any need for multiple signatures for Debian; for non-Debian,
> if deb sigs are convenient, use them.

deb sigs get a lot less convenient if Debian doesn't allow them in debs
uploaded to the archive.  I don't really care if Debian will ever use the
in-deb signatures somehow or not, but I'd like to see them allowed into the
archive.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the sha

Re: dpkg-sig support wanted?

[Florian Weimer]

* 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 verifies the
MD5 hashes, by the way. 8-)

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.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Thomas Bushnell BSG]

Anthony Towns  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 validity.

Don't they give the user the assurance that a Debian developer was
responsible for building and providing the package?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Thomas Bushnell BSG]

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 deb on ftp-master.

Isn't that a useful assurance?  Perhaps I trust the maintenance of
ftp-master, but not the maintenance of Joe Random Mirror.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

[Anthony Towns]

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 between Debian and
Ubuntu...

Regards,
aj



signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Anthony Towns]

On Fri, Nov 25, 2005 at 12:49:11PM -0800, Thomas Bushnell BSG wrote:
> Anthony Towns  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 validity.
> Don't they give the user the assurance that a Debian developer was
> responsible for building and providing the package?

Not really, they give the assurance that it was built by someone who at
some point possessed a key that at some point was considered sufficient
to identify a Debian developer or a buildd.

What assurance would you take from a package signed by Chip's old key?

(And why do you think it's actually helpful? Debian developers build
*lots* of crap, especially if you can't differentiate stuff uploaded to
Debian and not)

Cheers,
aj



signature.asc
Description: Digital signature