On Sat, 2021-12-04 at 02:43 +0000, Scott Kitterman wrote: > I think that there's a security consideration associated with all these > proposals for externalizing finding upstream updates. Good point. > If one of these services were ever compromised it would provide a > vector for offering substitute upstream code (at least for the cases > where upstream releases aren't both signed by upstream and verified in > Debian). I find that prospect concerning. I think the same concern should also apply to centralised upstream development infrastructure like GitHub and also individual upstream developers themselves. There isn't really any mitigation for malicious code being pushed out beyond commit/release signing (both unpopular) and (distributed) downstream code review. To mitigate the concern for upstream version monitoring we could prefer debian/watch when it exists but fall back to release-monitoring.org when one doesn't exist, have a tool to convert the Ayanita format into debian/watch and have dh_make and similar try to create an initial debian/watch by default. We need a culture of doing change review before updating to new upstream releases, but often that isn't necessarily feasible, especially for large projects with rapid change or when switching to new forks of existing tools. > Currently watch files and at least the redirectors I know of all run > on Debian infrastructure or on the systems of the Debian person doing > the update. Some run on debian.org servers, and many run on debian.net domains. However I don't think that that makes them immune to compromise. -- bye, pabs https://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part