What should be the proper practice to manage `.dsc` files on Reprepro?

[Yaobin Wen]

David & Vagrant,

Thank you for your advice! The idea that multiple people may want to sign
the same .dsc file makes a lot of sense to me.

After reading David's email about separating the .dsc files and their
signatures, I also thought about the management of these files. Over the
weekend, I looked at Reprepro again (because my company is using it). It
looks like Reprepro can include .dsc files themselves but not the signature
files (e.g., .asc or .gpg), so *I think this means I need some other tool
(instead of Reprepro) to manage the signature files and the relationship
between the .dsc file and the corresponding signature files. Am I right?*
I'm asking this because: With the signature combined with the .dsc file
directly, I can include the .dsc files into Reprepro; later when I get an
.dsc file from Reprepro, I can verify the signature directly to make sure
this is the authentic .dsc file I should use. With the signature(s)
separated from the .dsc files, when I obtain an .dsc file, I will need to
somehow obtain the corresponding signature file(s) in order to verify the
authenticity.

Nah, I'm not complaining that "oh this is becoming too complex." I'm still
trying to learn how I should properly manage the files with what tools. A
more general question is: *Is there an existing solution that can help
people verify the authenticity of the needed files (e.g., .dsc,
.orig.tar.gz, .buildinfo), recreate the build environment, and rebuild the
code?* I'm asking this because on https://buildinfo.debian.net/ I noticed
the sentence "It is not currently clear how these files could or should be
handled in practice, hence the creation of this server to investigate." *So
I'm wondering if this sentence still reflects the most current situation or
if there are already other tools but I'm not aware of yet*.

Thanks!
Yaobin


On Fri, May 27, 2022 at 3:22 PM Vagrant Cascadian <
vagrant at reproducible-builds.org> wrote:

> On 2022-05-27, David A. Wheeler wrote:
> > I think that in general *signatures* should be separated from *what
> > they are signing*, preferably by being different files.
> >
> > This solves reproducibility problems. It also solves other problems,
> > e.g., it's quite possible for multiple people to sign something (e.g.,
> > "I also approve of this") - that shouldn't change what was being
> > signed.
> >
> > Of course, it's possible to interpret a file as two parts, the part
> > being signed & the signatures. So it's definitely *possible* to
> > combine them. But there are risks that the split will be implemented
> > incorrectly. It's easier if they're always handled separately; it
> > reduces the risk of incorrect handling.
>
> Absolutely agreed!
>
> That said, in the context of Debian's .dsc files, there are decades of
> history here that are not likely to change... any time soon.
>
> Though really, the .dsc files themselves are in fact the signed metadata
> here; the actual data is the PAKAGAGE_VERSION.orig.tar.gz and other
> files that the .dsc file references. Though that still makes it a little
> tricky to have multi-party signatures...
>
>
> live well,
>   vagrant
>


-- 
Software Engineer
Mine Vision Systems <https://www.minevisionsystems.com/>
5877 Commerce St.
Suite 118
Pittsburgh PA, USA, 15206
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20220531/7e30e58a/attachment.htm>