On 08/27/2014 11:06 AM, Guillem Jover wrote: > Ah, hmmm, yeah make sense. It also does really make sense as an > additional file alongside the others referenced from the .dsc > metadata. As a minor detail, the .asc would not be included in the > .changes file when the orig.tar is not included either in the upload.
sure, that makes sense.
> I'm thinking dpkg-source would automatically include it if it finds it
> side by side the orig.tar.
I like that.
> But I'm not comfortable just adding it as is,
> I'd probably want to bump the minor version of the format. As this gets
> us to the problem that we currently conflate the .dsc file format version
> with the actual source format version.
I think you're saying you'd bump the minor version of the .dsc format,
right? What are the logistical consequences of this? is this the
"Format: 3.0 (quilt)" line, or would you add some additional entry to
the .dsc file to indicate the capability? I've only ever experienced
one transition in the version formats (the 1.0 → 3.0 (quilt)
transition), and that seemed like it was pretty involved. I hope this
won't involve that much complexity!
> It probably does not make sense to very the signature on unpack and
> fail hard by default, because most probably the user will not have the
> signers key.
I don't think we need to worry about policy around failing hard by
default right now -- i just want to make the info available first, and
then we can try to figure out sensible policy once the data is present.
But that said, i expect we'd only include upstream signatures in
situations where the upstream signing key is already present in
debian/upstream/signing-key.asc -- so in a 3.0 (quilt) package, the
check could be done as:
* verify the .dsc by the debian maintainer's key
* verify the debian.tar.gz by the digest in the .dsc
* extract debian/upstream/signing-key.asc from debian.tar.gz
* verify the upstream tarball against the upstream signing key
> I'm not sure if even verifying as warning might make
> sense as default either if it's just going to annoy people at large.
> But I could see either a new option to make it verify it at all (and
> fail hard), or to turn the verify from possibly a warning into a fatal
> error.
i think a warning on validation failure is a reasonable initial policy,
but i wouldn't want to block acceptance and distribution of the .asc on
wrangling over policy of exactly where it gets used.
Thanks for your prompt response on this, Guillem!
Regards,
--dkg
signature.asc
Description: OpenPGP digital signature
