Bug#727096: uscan: store signature for upstream tarball in debian/

[Sven Joachim]

On 2016-04-12 09:19 +0200, Ansgar Burchardt wrote:

> Paul Wise  writes:
>> On Tue, 22 Oct 2013 10:42:51 +0200 Ansgar Burchardt wrote:
>>> uscan would store the signature for the upstream tarball as
>>> obtained via pgpsigurlmangle=... in the debian/ directory
>>
>> ISTR another idea was to place the upstream signature alongside the
>> upstream tarball instead of inside the debian/ directory.
>>
>> foo_0.1.2.orig.tar.gz
>> foo_0.1.2.orig.tar.gz..asc
>>
>> AFAIR, there was some work in dak done already to allow this?
>
> Yes, but there was a bug and I somehow forgot about the patches in
> #759401 that Guillem Jover provided. So dak should now accept upstream
> signatures, dpkg in stable should ignore them (but not throw an error)
> and dpkg in unstable/testing will hopefully start to include them in the
> source package (.dsc) soon.
>
> For a given upstream tarball the upstream signature should go in a file
> with the extension `.asc`. For example, for
>   dune-common_2.4.1.orig.tar.xz
> the signature should be in
>   dune-common_2.4.1.orig.tar.xz.asc

FWIW, lintian 2.5.52 throws an error
("orig-tarball-missing-upstream-signature") if the file is not there.

> It should be safe for uscan to already create this file: older versions
> of dpkg should just ignore it.

Uscan already stores the upstream signature, albeit under a different
filename ending in .pgp.  All it needs to do is to create a link for it
under the name that dpkg-source and lintian expect (unless the upstream
tarball needs to be repacked, that is).

Cheers,
   Sven

Bug#727096: uscan: store signature for upstream tarball in debian/

[Ansgar Burchardt]

On Wed, 2016-04-13 at 01:15 +0800, Paul Wise wrote:
> On Tue, 2016-04-12 at 18:24 +0200, Ansgar Burchardt wrote:
> > Why include the fingerprint in the filename instead of just
> > including
> > multiple signatures in the single .asc file?  That is what we do
> > for InRelease and Release.gpg too.
> For a start: dak doesn't allow updating files in pool/

Yes, I mentioned that: "It also doesn't allow adding more
signatures later, but I don't think that's very important here."

Ansgar

Bug#727096: uscan: store signature for upstream tarball in debian/

[Paul Wise]

On Tue, 2016-04-12 at 18:24 +0200, Ansgar Burchardt wrote:

> Why include the fingerprint in the filename instead of just including
> multiple signatures in the single .asc file?  That is what we do for
> InRelease and Release.gpg too.

For a start: dak doesn't allow updating files in pool/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




signature.asc
Description: This is a digitally signed message part

Bug#727096: uscan: store signature for upstream tarball in debian/

[Ansgar Burchardt]

On Tue, 2016-04-12 at 21:52 +0800, Paul Wise wrote:
> On Tue, 2016-04-12 at 09:19 +0200, Ansgar Burchardt wrote:
> For a given upstream tarball the upstream signature should go in a
> > file
> > with the extension `.asc`. For example, for
> >   dune-common_2.4.1.orig.tar.xz
> > the signature should be in
> >   dune-common_2.4.1.orig.tar.xz.asc
> Is there any possibility to extend this to include the fingerprint,
> thus allowing for multiple signatures; for example one from upstream
> and one from the Debian maintainer?

Why include the fingerprint in the filename instead of just including
multiple signatures in the single .asc file?  That is what we do for
InRelease and Release.gpg too.

I know there are some small downsides: gpg only supports using the same
hash for multiple signature or it will only validate the first
signature. But one can still split the file and call gpg multiple times
to validate each signature. It also doesn't allow adding more
signatures later, but I don't think that's very important here.

On the upside, the current implementation uses a predictable filename
and dpkg in stable already understands it (at least in so far as it
will not give an error when trying to extract a source package
including a *.asc file).

Ansgar

Bug#727096: uscan: store signature for upstream tarball in debian/

[Paul Wise]

On Tue, 2016-04-12 at 12:06 -0400, Daniel Kahn Gillmor wrote:

> .asc files can already contain multiple signatures -- i guess i have no
> problem with splitting them out if we want, as long as the tooling for
> doing so is easy for people to use.

Having separate keys allows the addition of multiple sigs to be
independent. I'm not sure you can even add a new signature to an
existing signature file? In any case you are modifying the .asc file
every time and modifying files in the Debian archive is not allowed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




signature.asc
Description: This is a digitally signed message part

Bug#727096: uscan: store signature for upstream tarball in debian/

[Daniel Kahn Gillmor]

On Tue 2016-04-12 11:12:44 -0400, Paul Wise wrote:
> On Tue, 2016-04-12 at 10:26 -0400, Daniel Kahn Gillmor wrote:
>
>> I'm not sure that we need the []  in that specification.
>
> This allows for multiple signers: an upstream release team to have
> multiple signers attesting that the build of the source tarball from
> git is bitwise reproducible, or an upstream signature plus the Debian
> maintainer attesting that they downloaded a particular package.

.asc files can already contain multiple signatures -- i guess i have no
problem with splitting them out if we want, as long as the tooling for
doing so is easy for people to use.

> BTW, check-all-the-things uses `hokey lint` to encourage package
> maintainers to talk to their upstreams about OpenPGP:
>
>  
> https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/tree/data/openpgp
>
> I should probably include a link to the best practices.
>
>  https://help.riseup.net/en/security/message-security/openpgp/best-practices

Great, this is exactly the sort of ecosystem-shaping work we should be
encouraging.

--dkg

Bug#727096: uscan: store signature for upstream tarball in debian/

[Paul Wise]

On Tue, 2016-04-12 at 10:26 -0400, Daniel Kahn Gillmor wrote:

> I'm not sure that we need the  in that specification.

This allows for multiple signers: an upstream release team to have
multiple signers attesting that the build of the source tarball from git is 
bitwise reproducible, or an upstream signature plus the Debian
maintainer attesting that they downloaded a particular package.


>  * If problems are found with certain kinds of keys for software
>    signing, there is an easy way to do a rapid scan of the archive to
>    detect which keys might be vulnerable and encourage upstreams to fix
>    their practices

BTW, check-all-the-things uses `hokey lint` to encourage package
maintainers to talk to their upstreams about OpenPGP:

https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/tree/data/openpgp

I should probably include a link to the best practices.

https://help.riseup.net/en/security/message-security/openpgp/best-practices

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




signature.asc
Description: This is a digitally signed message part

Bug#727096: uscan: store signature for upstream tarball in debian/

[Daniel Kahn Gillmor]

On Tue 2016-04-12 10:00:09 -0400, Osamu Aoki wrote:
> I assume "create" means "create a copy of the upstream-generated
> signature" as foo_0.1.2.orig.tar.gz..asc which can be
> verified by the keyring debian/upstream/signing-key.pgp in the older
> package.

I'm not sure that we need the  in that specification.

> I am a bit confused what kind of assurance it brings to the end user.
>
> The Debian packager can put his random public key in
> debian/upstream/signing-key.pgp and sign a package with his secret key to
> generate foo_0.1.2.orig.tar.gz..asc.  The end-user gets
> false sense of security of checking signature but it really does not
> offer much.

I agree that this isn't a magic fix for any kind of cryptographic
provenance checking; it is as much 

However, it establishes more links in the chain that can be inspected,
automated, and in :

 * non-debian systems now have a specific location to look for the key
   that debian thinks is appropriate for upstream (this is debian
   collectively acting as a sort of corroborative certificate authority
   for software signatures)

 * If problems are found with certain kinds of keys for software
   signing, there is an easy way to do a rapid scan of the archive to
   detect which keys might be vulnerable and encourage upstreams to fix
   their practices

 * If a package is team-maintained, or changing maintainers, there is a
   chain-of-custody with respect to the upstream software signatures.

 * It could be used to detect *other* signatures made by the same
   signing key, in a sort of "certificate transparency" overview (this
   would require a lot of extra instrumentation)

> Also if a new upstream package is signed by a new upstream key, uscan
> using old key will fail. ...

sure -- this is something that a debian maintainer should notice and
verify via some other channel.  automating detection of these events and
helping the maintainer by calling attention to them is a good thing.

The point is that this is baseline data about cryptographic provenance,
and it's stuff that should be part of the standard software distribution
process that affects how people ship and update code.  It's at least as
relevant as the exact upstream tarball, so we should be recording it.

 --dkg

Bug#727096: uscan: store signature for upstream tarball in debian/

[Paul Wise]

On Tue, 2016-04-12 at 21:14 +0900, Osamu Aoki wrote:

> I assume "create" means "create a copy of the upstream-generated
> signature" as foo_0.1.2.orig.tar.gz..asc which can be
> verified by the keyring debian/upstream/signing-key.pgp in the older
> package.

Correct.

> I am a bit confused what kind of assurance it brings to the end user.

If the user has a trust path to upstream, they can be sure that Debian
hasn't modified the upstream tarball.

I think we had more use cases but can't remember, hopefully dkg (CCed)
remembers some of them. I expect it is mostly useful to Debian.

I expect this will be useful for binary transparency efforts:

https://pad.riseup.net/p/binary-transparency
https://github.com/FreeBSDFoundation/binary-transparency-notes
https://boingboing.net/2016/03/10/using-distributed-code-signatu.html

> Also if a new upstream package is signed by a new upstream key, uscan
> using old key will fail. ...

Yes, this is expected and should result in the Debian maintainer
investigating the situation and contacting upstream to clarify it.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




signature.asc
Description: This is a digitally signed message part

Bug#727096: uscan: store signature for upstream tarball in debian/

[Paul Wise]

On Tue, 2016-04-12 at 09:19 +0200, Ansgar Burchardt wrote:

> For a given upstream tarball the upstream signature should go in a file
> with the extension `.asc`. For example, for
>   dune-common_2.4.1.orig.tar.xz
> the signature should be in
>   dune-common_2.4.1.orig.tar.xz.asc

Is there any possibility to extend this to include the fingerprint,
thus allowing for multiple signatures; for example one from upstream
and one from the Debian maintainer? Having multiple detached signatures
is also planned for the reproducible builds .buildinfo files IIRC.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




signature.asc
Description: This is a digitally signed message part

Bug#727096: uscan: store signature for upstream tarball in debian/

[Osamu Aoki]

Hi,

On Tue, Apr 12, 2016 at 09:19:41AM +0200, Ansgar Burchardt wrote:
> Paul Wise  writes:
> > On Tue, 22 Oct 2013 10:42:51 +0200 Ansgar Burchardt wrote:
> >> uscan would store the signature for the upstream tarball as
> >> obtained via pgpsigurlmangle=... in the debian/ directory
> >
> > ISTR another idea was to place the upstream signature alongside the
> > upstream tarball instead of inside the debian/ directory.
> >
> > foo_0.1.2.orig.tar.gz
> > foo_0.1.2.orig.tar.gz..asc
> >
> > AFAIR, there was some work in dak done already to allow this?
> 
> Yes, but there was a bug and I somehow forgot about the patches in
> #759401 that Guillem Jover provided. So dak should now accept upstream
> signatures, dpkg in stable should ignore them (but not throw an error)
> and dpkg in unstable/testing will hopefully start to include them in the
> source package (.dsc) soon.
> 
> For a given upstream tarball the upstream signature should go in a file
> with the extension `.asc`. For example, for
>   dune-common_2.4.1.orig.tar.xz
> the signature should be in
>   dune-common_2.4.1.orig.tar.xz.asc
> 
> It should be safe for uscan to already create this file: older versions
> of dpkg should just ignore it.

Sounds interesting...

I assume "create" means "create a copy of the upstream-generated
signature" as foo_0.1.2.orig.tar.gz..asc which can be
verified by the keyring debian/upstream/signing-key.pgp in the older
package.

I am a bit confused what kind of assurance it brings to the end user.

The Debian packager can put his random public key in
debian/upstream/signing-key.pgp and sign a package with his secret key to
generate foo_0.1.2.orig.tar.gz..asc.  The end-user gets
false sense of security of checking signature but it really does not
offer much.

Also if a new upstream package is signed by a new upstream key, uscan
using old key will fail. ...

I am a bit confused what kind of ecosystem will we bring and offer to
the people.

Osamu

Bug#727096: uscan: store signature for upstream tarball in debian/

[Ansgar Burchardt]

Paul Wise  writes:
> On Tue, 22 Oct 2013 10:42:51 +0200 Ansgar Burchardt wrote:
>> uscan would store the signature for the upstream tarball as
>> obtained via pgpsigurlmangle=... in the debian/ directory
>
> ISTR another idea was to place the upstream signature alongside the
> upstream tarball instead of inside the debian/ directory.
>
> foo_0.1.2.orig.tar.gz
> foo_0.1.2.orig.tar.gz..asc
>
> AFAIR, there was some work in dak done already to allow this?

Yes, but there was a bug and I somehow forgot about the patches in
#759401 that Guillem Jover provided. So dak should now accept upstream
signatures, dpkg in stable should ignore them (but not throw an error)
and dpkg in unstable/testing will hopefully start to include them in the
source package (.dsc) soon.

For a given upstream tarball the upstream signature should go in a file
with the extension `.asc`. For example, for
  dune-common_2.4.1.orig.tar.xz
the signature should be in
  dune-common_2.4.1.orig.tar.xz.asc

It should be safe for uscan to already create this file: older versions
of dpkg should just ignore it.

Ansgar

Bug#727096: uscan: store signature for upstream tarball in debian/

[Paul Wise]

On Tue, 22 Oct 2013 10:42:51 +0200 Ansgar Burchardt wrote:

> uscan would store the signature for the upstream tarball as
> obtained via pgpsigurlmangle=... in the debian/ directory

ISTR another idea was to place the upstream signature alongside the
upstream tarball instead of inside the debian/ directory.

foo_0.1.2.orig.tar.gz
foo_0.1.2.orig.tar.gz..asc

AFAIR, there was some work in dak done already to allow this?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




signature.asc
Description: This is a digitally signed message part

Bug#727096: uscan: store signature for upstream tarball in debian/

[Ansgar Burchardt]

Package: devscripts
Version: 2.13.4
Severity: wishlist
File: /usr/bin/uscan

Hi,

It would be nice if uscan would store the signature for the upstream tarball as
obtained via pgpsigurlmangle=... in the debian/ directory. This would allow
checking the signature later without having to rely on the file staying on the
upstream site.

The file could for example be stored as debian/upstream-signature.pgp or
debian/upstream-signature_version.pgp.

Regards,
Ansgar


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org