On Mon, Jul 31, 2017 at 3:55 AM, Andrey Rahmatullin <[email protected]> wrote:
> On Mon, Jul 31, 2017 at 05:46:35AM -0400, Paul Wise wrote: > > > And there I do want uscan to actually check the signature of > > > the new orig tarball it downloads. But that also means that as > > > I'm using the orig tarball from upstream (and pristine-tar is > > > just a weird way of storing it) I think it is semantically > > > correct to include the .asc files in the .changes file. > > > > Perhaps you need pristine-tar to also store the .asc file and check it > > out when appropriate. > This is the problem: pristine-tar is not about .asc, it's not even about > source packages or their parts, it's just "regenerate an exact copy of a > pristine upstream tarball" (and while the manpage talks about orig > tarballs I don't know about any specific support related to orig tarballs > and not just any tarballs). Maybe something else should be extended, > pristine-tar seems like a wrong place. > > -- > WBR, wRAR > Please note that when upstream signs a tarball, any changes to that tarball such as those done by pristine tar or when making a dsfg tarball invalidates the signature. Two practices that make this particularly annoying are recompressing (a .tar.Z.asc is useless for verifying a .tar.xz) and on the fly tar generation. The two methods that I have seen to help with these issues are uncompressed signing where a tar.asc is used to verify both tar.gz and tar.xz, just decompress and verify the signature on the tarball, and extended git tag signatures (multiple proposals exist). -- -- Ben Hildred Automation Support Services
