Post ASgXMQ3wYdNx3PKogy by kravietz@agora.echelon.pl
 (DIR) More posts by kravietz@agora.echelon.pl
 (DIR) Post #ASg0wl2MksZu2jJh3Y by kravietz@agora.echelon.pl
       2023-02-14T17:09:34.857411Z
       
       0 likes, 0 repeats
       
       For the last few months I have been signing all my software releases (C, #Python, #Ansible) using #sigstore per this article[^1].With any CI/CD system like GitHub it’s really  a matter of adding rather simple pipeline, example of which you can see in my actual project[^2]. When you create a tag, the workflow creates the usual release but also adds two extra signature files[^3].Right now you could validate them in your build pipeline using the same sigstore command-line utility that produces them, but there’s currently quite a long open merge requests for integration with sigstore in projects such as Ansible[^4] and pip-audit[^5], NPM[^6] and it makes a lot of sense.Where sigstore will make a huge qualitative difference are specifically these CI/CD tools - pip, npm, Maven etc. Just so that understand the scale of the problem, while building an average applications, these tools will pull hundreds of third-party dependencies which come from open repositories (PyPa, NPM, Maven etc), and these dependencies get routinely backdoored, taken over etc. With widespread support for sigstore myself, as a security officer, can quite easily push policies such as “all packages we compile into out project must be sigstore-signed”, which in turn creates pressure on the package maintainers to actually go and sign them, thus limiting the problem of rogue packages.Sigstore is not a silver bullet but the reality of security engineering is that there’s no silver bullets at all, just a lot of slow, gradual changes that eventually take us from a state where an application just welcomes people to break in, to a state where you need people on the defending end need to screw up (which is much less common).[^1]: https://krvtz.net/posts/trusted-software-supply-chains-with-sigstore.html [^2]: https://github.com/kravietz/ipfs-config/blob/main/.github/workflows/release.yaml [^3]: https://github.com/kravietz/ipfs-config/releases/tag/v1.3.1 [^4]: https://github.com/ansible/ansible-sign/issues/32 [^5]: https://github.com/pypa/pip-audit/issues/271 [^6]: https://github.blog/2022-08-08-new-request-for-comments-on-improving-npm-security-with-sigstore-is-now-open/
       
 (DIR) Post #ASgXMFv4GmLNaz6aTA by kirschwipfel@nerdculture.de
       2023-02-14T22:52:58Z
       
       0 likes, 0 repeats
       
       > thus limiting the problem of rogue packagesHow do you expect this to work? It doesn't help against typo sqashing, projects sold to evil minded or invaded repos. In all these cases the pacjes will he signed, but content is malicious.> pressure on the package maintainers to actually go and sign them, Are you paying them for maintenance?@kravietz
       
 (DIR) Post #ASgXMQ3wYdNx3PKogy by kravietz@agora.echelon.pl
       2023-02-14T23:12:45.319307Z
       
       0 likes, 0 repeats
       
       @kirschwipfelAs a build pipeline maintainer you have quite a lot of flexibility on constraining the package origins you accept, including who signed it and who built it. So yes, that pretty much eliminates  package takeovers. It doesn't eliminate typosquatting where the wrong package name is in the project from the beginning, but in high profile projects that's usually not the case thanks to other controls, such as code reviews.And yes, at the scale of the projects we're talking about, the package developers are usually paid for maintaining them and there's a lot of motivation to keep their overall security posture at the best available level.