On Wed, Jun 12, 2024 at 06:50:44AM +0200, Ansgar 🙀 wrote: > On Wed, 2024-06-12 at 06:25 +0800, Sean Whitton wrote: > > As tag2upload is security-sensitive, the design has had careful, > > independent security review from Russ Allbery and Jonathan McDowell, > > As I said several times before: the implementation has known security > bugs (unless you fixed them). But I guess this is going to get ignored > again anyway... Reviewing the design doesn't help with this.
In the interest of avoiding repetition it would help to establish a reference to earlier discussions. If you don't like to dig into message ids, you probably still remember on which list it was discussed and maybe also roughly when or on what subject. > In addition it reintroduces trust in weak cryptographic hashes which > effort was spent to remove. Thanks for reminding. While I've seen arguments in favour of the weaknesses of sha1 not affecting our use much, the xz-incident changes the weights of those arguments for me. I am now wondering whether we can be more proactive about changing the hash function used by git. For new repositories, this seems as simple as git init --object-format=sha256. Doing so will make repositories inaccessible to people running buster or older and I guess we can live with that limitation. It is not clear to me how repositories are converted. To me it seems plausible to deny use of sha1 hashes with debpush at this time (even though that is not implemented right now). I note that use of weak hashes in the current tag2upload is not a fundamental blocker but something that I expect proponents to work on in case the GR passes. Would one of the proponents confirm that they see this as worth spending their time on (on the condition that the GR passes)? > > ftpmaster stated a hard requirement that dak has to be able to > > completely re-perform the verification of maintainer intent done by the > > tag2upload service. That goal cannot be met without fatally undermining > > the tag2upload design and user experience. > > That's not the only issue. Known security issues are another. > > In addition from the history of WebPKI compromises, it should we well > understood that having several paths to certificate issuance is not a > good idea. Several paths to introduce source to Debian has similar > problems. I think you this depends on the bigger picture. When the /usr-merge transition was started, it was repeatedly sold as opt-in, but it really was not meant as opt-in. Maybe tag2upload is similar. While the mail thread suggests that it does not have to be used, I wouldn't be surprised to be talking about terminating non-git uploads later. Once that happens, we'd back to one path of issuance and that one path is tag2upload then. It is not entirely clear whether this is the vision or not and to me this vision would make the argument for tag2upload stronger due to the reason you give. We only really have two ways of changing the upload process. Either we temporarily add a new process and later remove the old process or we do a flag-day transition. I guess that most of us agree that doing a flag-day transition from .dsc uploads to git-debpush would not pass muster. So we have little options but adding it if we agree that the upload process needs changes. > > THE DESIGN & IMPLEMENTATION ARE LATE-STAGE > > > > We wish to be clear that tag2upload can be deployed without *any* > > code changes to dak. It just needs to be given a suitably trusted > > key, very similar to how buildds have trusted keys. > > And we also remove the Debian Maintainer role as dak would no longer > know who uploaded the package? Debian is larger than only Debian > Developers. This is a policy aspect. When we need to revoke a key used for uploading this happens via keyring maintainers as far as I understand, but in urgent cases it is ftp master who can also deny upload rights more quickly than via a keyring update. In moving to tag2upload as a service external to ftp, we partially move this capability from ftp master to the entity running tag2upload (DSA afaiui). Is there a sensible way to leave this policy aspect with the ftp team when using the tag2upload service? In effect, I'm asking whether ftp could somehow provide an authorization oracle to be used by tag2upload. > If only one could use regular git instead of a custom, non-standard VCS > built on top of Git that makes some workflows impossible and team > maintenance harder by not supporting publishing intermediate work. :-( Even though the people behind the tag2upload work are the same as dgit, the tag2upload service has been carefully designed to actually work with most maintainer views. It also uploads to dgit, but I think tag2upload would also work if that dgit part were skipped (please correct me if I'm wrong about this). Hence, tag2upload provides a very important value to me: I then get a an authentication chain from the Debian archive signing key to the actual git object used for uploading. That is a property that I would formerly only get from using dgit and only for the dgit view. With tag2upload, we would be authenticating actual maintainer tags of maintainer histories on salsa from the archive signing key. To me, this is a significant step affecting my workflows in a positive way. Helmut
