On Tue, Dec 29, 2020 at 8:08 PM Brennan Ashton <bash...@brennanashton.com> wrote:
> On Tue, Dec 29, 2020 at 5:33 PM Greg Stein <gst...@gmail.com> wrote: > > One of things that we will likely do is perform a scan of any > > Action/workflow .yml at commit time, to ensure that any "uses:" is > defined > > with a hash rather than a tag. That should prevent the kind of attack > Jarek > > described where Action FOO@v7 does something very different today, than > it > > did yesterday. > > It would be nice if we could keep using tags from known verified > sources like github, > microsoft, etc.. which seems to be the case now. They make fairly > frequent changes > to improve the stability of the actions and without a good way to know > when to bump > the SHA that is going to be a pain. > That's a great point. Sure. Certainly apache/* we can allow it to "float" with HEAD, pin it to a tag, or to use a SHA. ie. the most flexible choices For trustedcorp/* we could allow a tag or a SHA, but no floating/unpinned. And so on. We can probably trust Microsoft and its GitHub subsidiary without reservation. But we'll likely need to make a call for other third-parties that we want to whitelist. Forking a third party Action into the apache/* space provides flexibility, no restrictions, and you can always pull down new changes or issue PRs upstream. A bit of work? Some, yes. Does it rise to the level of a problem? Welp, that's what we're exploring :-) TBH I don't see how the threat surface here is that much different > than pulling down > packages from pypi to npm at build time. > And that is why those packages should be pinned and checksums verified, too. Do people do that? Nope. Should they? Yup. (and Infra falls into the "we could do better, too"; not casting stones) (and yes, I'm aware of the past hacks via both those package repositories) While this change caught us off guard it was not that hard to get > things moving again. > Kind of got to us, too. Not a call that I would have liked to make. > It would be nice in the future changes that will very likely break > things (urgent or not) would be CCd > to the Incubator General mailing list. Not all of us have found our > way to the right mailing lists. > We try to give heads-up to users@ when we can (on all Infra topics that might affect users), and builds@ when it is build-related. All committers can subscribe to users@. builds@ is a public list, so I think it would be fine for anybody involved in the Incubator to forward from the builds@ list over to public general@, but I do not believe that is a call for Infra to make. general@ is not "our list" to decide on what/how to use. Cheers, -g
