Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

2019-07-29 Thread Daniel Kahn Gillmor
On Sat 2019-07-27 21:52:55 +0100, Jonathan McDowell wrote:
> On Fri, Jul 26, 2019 at 09:18:29PM +0100, Sean Whitton wrote:
>> For the purposes of tag2upload work, would you mind confirming this:
>> 
>> On Tue 23 Jul 2019 at 06:38AM +01, Sean Whitton wrote:
>> 
>> > AIUI a fingerprint fails to uniquely identify a PGP key unless you also
>> > include the cryptographic algorithm that was used and the key size.  So
>> > for example, my current key is uniquely identified by writing both 4096R
>> > and 8DC2487E51ABDD90B5C4753F0F56D0553B6D411B.
>> >
>> > Even though it's unlikely we'll get a clash of fingerprints within the
>> > Debian keyring, it seems the algorithm and keysize ought to be included
>> > alongside the fingerprint, if the above is right.
>
> My understanding is this was true in the days of v3 keys/fingerprints
> but is not the case for v4. If we get to the point we find a collision
> then that's a SHA1 issue that's going to cause bigger issues.

Noodles' understanding is correct.  That problem is one of the reasons
that the v3 format is deprecated.

 --dkg



Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

2019-07-27 Thread Jonathan McDowell
On Sat, Jul 27, 2019 at 10:40:00PM +0100, Ian Jackson wrote:
> Jonathan McDowell writes ("Bug#932753: tag2upload should record git tag 
> signer info in .dsc [and 1 more messages]"):
> > My understanding is this was true in the days of v3 keys/fingerprints
> > but is not the case for v4. If we get to the point we find a collision
> > then that's a SHA1 issue that's going to cause bigger issues.
> 
> It would be good to prepare for changing the fingerprint hash
> function.  Would including these parameters do that ?  I think it
> would, provided that "hash-algo" is in fact the algorithm used for the
> fingerprint hash.
> 
> An alternative, perhaps, is to leave this out now, and intend to
> introduce a `fingnerprintv5' value later.

A v5 fingerprint is SHA256 based and 32 bytes (64 ASCII characters)
long.

J.

-- 
Beware of programmers carrying screwdrivers.
This .sig brought to you by the letter X and the number 23
Product of the Republic of HuggieTag



Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

2019-07-27 Thread Ian Jackson
Jonathan McDowell writes ("Bug#932753: tag2upload should record git tag signer 
info in .dsc [and 1 more messages]"):
> My understanding is this was true in the days of v3 keys/fingerprints
> but is not the case for v4. If we get to the point we find a collision
> then that's a SHA1 issue that's going to cause bigger issues.

It would be good to prepare for changing the fingerprint hash
function.  Would including these parameters do that ?  I think it
would, provided that "hash-algo" is in fact the algorithm used for the
fingerprint hash.

An alternative, perhaps, is to leave this out now, and intend to
introduce a `fingnerprintv5' value later.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

2019-07-27 Thread Jonathan McDowell
On Fri, Jul 26, 2019 at 09:18:29PM +0100, Sean Whitton wrote:
> For the purposes of tag2upload work, would you mind confirming this:
> 
> On Tue 23 Jul 2019 at 06:38AM +01, Sean Whitton wrote:
> 
> > AIUI a fingerprint fails to uniquely identify a PGP key unless you also
> > include the cryptographic algorithm that was used and the key size.  So
> > for example, my current key is uniquely identified by writing both 4096R
> > and 8DC2487E51ABDD90B5C4753F0F56D0553B6D411B.
> >
> > Even though it's unlikely we'll get a clash of fingerprints within the
> > Debian keyring, it seems the algorithm and keysize ought to be included
> > alongside the fingerprint, if the above is right.

My understanding is this was true in the days of v3 keys/fingerprints
but is not the case for v4. If we get to the point we find a collision
then that's a SHA1 issue that's going to cause bigger issues.

J.

-- 
] https://www.earth.li/~noodles/ []  I'm absolutely  [
]  PGP/GPG Key @ the.earth.li[]  convinced one day soon I'm going  [
] via keyserver, web or email.   [] to get "masturbation" and  [
] RSA: 4096/0x94FA372B2DA8B985   []   "meditation" mixed up.   [



Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

2019-07-27 Thread Sean Whitton
Hello PGP experts,

For the purposes of tag2upload work, would you mind confirming this:

On Tue 23 Jul 2019 at 06:38AM +01, Sean Whitton wrote:

> AIUI a fingerprint fails to uniquely identify a PGP key unless you also
> include the cryptographic algorithm that was used and the key size.  So
> for example, my current key is uniquely identified by writing both 4096R
> and 8DC2487E51ABDD90B5C4753F0F56D0553B6D411B.
>
> Even though it's unlikely we'll get a clash of fingerprints within the
> Debian keyring, it seems the algorithm and keysize ought to be included
> alongside the fingerprint, if the above is right.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

2019-07-27 Thread Sean Whitton
Hello,

On Tue 23 Jul 2019 at 10:14PM +01, Ian Jackson wrote:

> Sean Whitton writes ("Bug#932753: tag2upload should record git tag signer 
> info in .dsc [and 1 more messages]"):
>> AIUI a fingerprint fails to uniquely identify a PGP key unless you also
>> include the cryptographic algorithm that was used and the key size.  So
>> for example, my current key is uniquely identified by writing both 4096R
>> and 8DC2487E51ABDD90B5C4753F0F56D0553B6D411B.
>>
>> Even though it's unlikely we'll get a clash of fingerprints within the
>> Debian keyring, it seems the algorithm and keysize ought to be included
>> alongside the fingerprint, if the above is right.
>
> In this message[1]
>
> [GNUPG:] VALIDSIG 559AE46C2D6B6D3265E7CBA1E3E3392348B50D39 2019-07-20 
> 1563636558 0 4 0 1 8 01 559AE46C2D6B6D3265E7CBA1E3E3392348B50D39
>   
>  ^^^
>
> I think I want to include `1' for pubkey-algo and `8' for hash-algo
> then ?

Assuming this fact about PGP key fingerprints is not a misunderstanding
on my part, yes.  Sending a separate e-mail to ask the experts.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

2019-07-23 Thread Ian Jackson
Sean Whitton writes ("Bug#932753: tag2upload should record git tag signer info 
in .dsc [and 1 more messages]"):
> AIUI a fingerprint fails to uniquely identify a PGP key unless you also
> include the cryptographic algorithm that was used and the key size.  So
> for example, my current key is uniquely identified by writing both 4096R
> and 8DC2487E51ABDD90B5C4753F0F56D0553B6D411B.
> 
> Even though it's unlikely we'll get a clash of fingerprints within the
> Debian keyring, it seems the algorithm and keysize ought to be included
> alongside the fingerprint, if the above is right.

In this message[1]

[GNUPG:] VALIDSIG 559AE46C2D6B6D3265E7CBA1E3E3392348B50D39 2019-07-20 
1563636558 0 4 0 1 8 01 559AE46C2D6B6D3265E7CBA1E3E3392348B50D39

   ^^^

I think I want to include `1' for pubkey-algo and `8' for hash-algo
then ?

Ian.

[1] Part of the output of
  gpgv --status-fd=2 --keyring=/usr/share/keyrings/debian-keyring.gpg < 
../bpd/dgit_9.4.dsc

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

2019-07-22 Thread Sean Whitton
Hello,

On Mon 22 Jul 2019 at 07:55PM +01, Ian Jackson wrote:

> That means the original "uploader" information (ie the identity of the
> person signing the git tag) is not any more present in the source
> package.  To rememdy that I propose the following new field:
>
>   Git-Tag-Info: FINGERPRINT Firstname Surname 
>
> The parsing rules are: the first word is the fingerprint entirely in
> hex.  The rest is from the tag's "tagger" line (and may not match).

AIUI a fingerprint fails to uniquely identify a PGP key unless you also
include the cryptographic algorithm that was used and the key size.  So
for example, my current key is uniquely identified by writing both 4096R
and 8DC2487E51ABDD90B5C4753F0F56D0553B6D411B.

Even though it's unlikely we'll get a clash of fingerprints within the
Debian keyring, it seems the algorithm and keysize ought to be included
alongside the fingerprint, if the above is right.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

2019-07-22 Thread Russ Allbery
Ian Jackson  writes:
> Ian Jackson writes ("Re: Bug#932753: tag2upload should record git tag signer 
> info in .dsc [and 1 more messages]"):
>> Russ Allbery writes ("Bug#932753: tag2upload should record git tag signer 
>> info in .dsc [and 1 more messages]"):
>> > Git-Tag-Info: fingerprint=FINGERPRINT
>> > Git-Tag-Tagger: Firstname Surname 
>> 
>> This LGTM if other people like the look.

> It occurs to me based on another conversation I had: should this be in
> .dsc or .changes ?

I personally think it should be in the *.dsc file because that makes it
more visible directly in the archive if we need to track down how a
package was uploaded for some reason.  (This is the security engineer in
me talking, probably.)  We probably *could* track down the same
information via *.changes and other systems, but I don't see a reason to
not put it in the *.dsc file and conceptually think of it as "replacing"
the current uploader signature on the *.dsc file.

That said, I could be missing some subtlety of why the *.changes file
would be better.

-- 
Russ Allbery (r...@debian.org)   <http://www.eyrie.org/~eagle/>



Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

2019-07-22 Thread Ian Jackson
Ian Jackson writes ("Re: Bug#932753: tag2upload should record git tag signer 
info in .dsc [and 1 more messages]"):
> Russ Allbery writes ("Bug#932753: tag2upload should record git tag signer 
> info in .dsc [and 1 more messages]"):
> > Git-Tag-Info: fingerprint=FINGERPRINT
> > Git-Tag-Tagger: Firstname Surname 
> 
> This LGTM if other people like the look.

It occurs to me based on another conversation I had: should this be in
.dsc or .changes ?

Ian.



Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

2019-07-22 Thread gregor herrmann
On Mon, 22 Jul 2019 20:54:29 +0100, Ian Jackson wrote:

> > Unfortunately , doing something extensible within the field requires adding
> > a separator, which in turn requires dealing with escaping, and thus is
> > kind of a mess.  Given that, what if you instead used two fields:
> > 
> > Git-Tag-Info: fingerprint=FINGERPRINT
> > Git-Tag-Tagger: Firstname Surname 
> 
> This LGTM if other people like the look.

I wonder if just

Git-Tag-Fingerprint: FINGERPRINT

for the first field might be not only simpler but also enough?
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature


Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

2019-07-22 Thread Ian Jackson
Russ Allbery writes ("Bug#932753: tag2upload should record git tag signer info 
in .dsc [and 1 more messages]"):
> One thing that jumps out at me here is that this field isn't extensible,
> since anything after the first space-separated word has to be taken to be
> the tagger line.

Hi.  Thanks for the review.

How hilarious that you are making this point back to me now here :-).

> Unfortunately , doing something extensible within the field requires adding
> a separator, which in turn requires dealing with escaping, and thus is
> kind of a mess.  Given that, what if you instead used two fields:
> 
> Git-Tag-Info: fingerprint=FINGERPRINT
> Git-Tag-Tagger: Firstname Surname 

This LGTM if other people like the look.

> That also allows the tagger field to be defined has having the same syntax
> as Maintainer (or one of the other existing RFC-2822-style fields we
> have), which I think increases the chances that parsers will get this
> right.

Right.  I already need and have code to turn a git-style
committer/author/tagger line into deb822 form.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

2019-07-22 Thread Russ Allbery
Ian Jackson  writes:

> That means the original "uploader" information (ie the identity of the
> person signing the git tag) is not any more present in the source
> package.  To rememdy that I propose the following new field:

>   Git-Tag-Info: FINGERPRINT Firstname Surname 

> The parsing rules are: the first word is the fingerprint entirely in
> hex.  The rest is from the tag's "tagger" line (and may not match).

One thing that jumps out at me here is that this field isn't extensible,
since anything after the first space-separated word has to be taken to be
the tagger line.

Unfortunately, doing something extensible within the field requires adding
a separator, which in turn requires dealing with escaping, and thus is
kind of a mess.  Given that, what if you instead used two fields:

Git-Tag-Info: fingerprint=FINGERPRINT
Git-Tag-Tagger: Firstname Surname 

and then Git-Tag-Info could be extended later using additional key/value
pairs to hold other information, use spaces or commas between attributes,
and so forth?  For instance, that would let us add the date later if it
looked like that might be useful for some reason.

That also allows the tagger field to be defined has having the same syntax
as Maintainer (or one of the other existing RFC-2822-style fields we
have), which I think increases the chances that parsers will get this
right.

-- 
Russ Allbery (r...@debian.org)   



Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

2019-07-22 Thread Ian Jackson
Hi.  I am consulting on the name and syntax of a new field I intend to
put in .dsc's.

This is for our tag-to-upload service[1], as described here:
  https://spwhitton.name/blog/entry/tag2upload/

The tag2upload service will take a signed git tag, and verify it
against the Debian keyrings and dm.txt.  It then turns that into a
source package which it signs with its own key.

That means the original "uploader" information (ie the identity of the
person signing the git tag) is not any more present in the source
package.  To rememdy that I propose the following new field:

  Git-Tag-Info: FINGERPRINT Firstname Surname 

The parsing rules are: the first word is the fingerprint entirely in
hex.  The rest is from the tag's "tagger" line (and may not match).

Consumers which want to know which OpenPGP key ws used should use
FINGERPRINT.  Consumers which want to send email should use the RHS.

This syntax does not contain the signature date, nor the tag message,
nor any OpenPGP cert name.  An OpenPGP cert name would be a pain to
provide in a securely meaningful way.  The tag/signature date is not
that important I think (and might be annoying to extract from gpgv).

I think consumers won't need that information.

It also eldides some tag2upload-specific metadata, info about git
branch formats, and so on, but I think a .dsc consumer does not need
that.

Comments welcome.

If you are likely to have an opinion, please reply as soon as you
can, since I hope to do the engineering work to make this thing
production-ready as soon as the relevant design reviews etc. are done.

If it will take you more than a few days to comment, please reply
right away with a holding mail saying when you hope to find the time
to write a substantive reply.

Thanks,
Ian.

[1] The service is still a prototype, but will hopefully be deployed
soon, after some review, privsep work, integration discussions, etc.