<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">David & Vagrant,</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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.</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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 <b>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?</b> 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.</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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: <b>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?</b> I'm asking this because on <a href="https://buildinfo.debian.net/">https://buildinfo.debian.net/</a> 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." <b>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</b>.</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Thanks!</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Yaobin</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 27, 2022 at 3:22 PM Vagrant Cascadian <<a href="mailto:vagrant@reproducible-builds.org" target="_blank">vagrant@reproducible-builds.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2022-05-27, David A. Wheeler wrote:<br>
> I think that in general *signatures* should be separated from *what<br>
> they are signing*, preferably by being different files.<br>
><br>
> This solves reproducibility problems. It also solves other problems,<br>
> e.g., it's quite possible for multiple people to sign something (e.g.,<br>
> "I also approve of this") - that shouldn't change what was being<br>
> signed.<br>
><br>
> Of course, it's possible to interpret a file as two parts, the part<br>
> being signed & the signatures. So it's definitely *possible* to<br>
> combine them. But there are risks that the split will be implemented<br>
> incorrectly. It's easier if they're always handled separately; it<br>
> reduces the risk of incorrect handling.<br>
<br>
Absolutely agreed!<br>
<br>
That said, in the context of Debian's .dsc files, there are decades of<br>
history here that are not likely to change... any time soon.<br>
<br>
Though really, the .dsc files themselves are in fact the signed metadata<br>
here; the actual data is the PAKAGAGE_VERSION.orig.tar.gz and other<br>
files that the .dsc file references. Though that still makes it a little<br>
tricky to have multi-party signatures...<br>
<br>
<br>
live well,<br>
  vagrant<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>Software Engineer</div><a href="https://www.minevisionsystems.com/" title="http://www.minevisionsystems.com" style="color:rgb(17,85,204)" target="_blank">Mine Vision Systems</a><br>5877 Commerce St. <br>Suite 118<br>Pittsburgh PA, USA, 15206<br></div></div>