Re: Using release-monitoring.org [was: uscan roadmap]
On December 5, 2021 1:51:48 AM UTC, Paul Wise <pabs@debian.org> wrote:
>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.
>
Never claimed it did, but the knowledge that our security posture isn't invulnerable isn't an argument for making it worse.
Scott K
Reply to: