You shouldn’t trust Trusted Publishing
https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing
#python #security #oss
Remote
yossarian
@yossarian@infosec.exchange
mastodon 4.8.0-alpha.3+glitchopen source interloper; attracts bugs easily
אַ ביסל ייִדיש־פּאָסטינג
1653 Followers
143 Following
50 Posts
Joined November 11, 2022
website:
github:
OID:
1.3.6.1.4.1.55738
it's not pull_request_target
there's no way it's pull_request_target
it was pull_request_target
Brocards for vulnerability triage
https://blog.yossarian.net/2026/04/11/Brocards-for-vulnerability-triage
@trailofbits@infosec.exchange recently spent several months contributing to zizmor, and wrote up their improvements here:
https://blog.trailofbits.com/2026/05/22/we-hardened-zizmors-github-actions-static-analyzer/
This work was really great: they got into some of the low and ugly bits that I’ve been procrastinating on, and in the process made zizmor significantly more correct and useful. Thanks to @DarkaMaul@infosec.exchange in particular for his hard and thoughtful work on anchors and expression parsing correctness!
people somewhat frequently complain about Python packaging’s assumption that each package can only resolve to a single version, but I actually think that was a pretty great outcome compared to having 3+ incompatible versions of the same package in your dep tree. Good example of constraints (even unintended ones) being liberating
gentleman's medium, n.: assigning a low-sev vulnerability a medium to get the reporter to stop quoting CVSS metrics as you
Replying to
so many downstream questions not answered by the docs: can background and wait be used with expressions, or just literal booleans? will this eventually work with composite actions too?
zizmor 1.24 is released! lots of bugfixes and features/enhancements:
Registering my dissatisfaction with GitHub
https://blog.yossarian.net/2026/04/29/Registering-my-dissatisfaction-with-GitHub
I actually can't think of a more frustrating place to put this button
Replying to
the JSON schema claims that composite actions support parallel but the runners suggest otherwise
Replying to
(this seems like a cool feature, but I'm also completely confused by _how_ it works given how much load-bearing code there is around actions ordering/initialization and the order in which pre/post-triggers for actions fire.)
it's cool when you spend 10 minutes writing an issue and GitHub decides to route it straight to hell instead
huge thanks to @veeso_dev@hachyderm.io for sponsoring me on GitHub!
(sponsors are part of what keeps zizmor sustainable. please consider sponsoring!)
slopping my hogs (prompting my agents)
copilot was already pretty mid, impressive how they’ve managed to make me dislike it even more by exhausting my quota on nothing except inline suggestions in…24 hours
on one hand, the competitive market is a compelling theory. on the other hand, billions of dollars have failed to produce an EDR that doesn’t suck shit
the best part about filing taxes in NYC is getting grilled about yonkers
this repo's issue indexing has been broken for over two weeks
Replying to
@bitprophet do you live in YONKERS? did you pay taxes in YONKERS? have you ever paid taxes in YONKERS? have you ever thought about paying taxes in YONKERS? would you ever consider paying taxes in YONKERS?
Replying to
I.e. I was sort of originally worried about erosion of norms among pre-existing community members, but that doesn't seem to be what's happening. instead we have an absolute avalanche of first-time contributors who are doing drive-by PRs and not sticking around long enough to learn how to properly engage with projects
Replying to
@djc@hachyderm.io definitely, I think it's a tradeoff that has worked well for Python in particular thanks to language properties. I actually think Rust's tradeoff is very defensible, it's more ecosystems like JS that I have a bone to pick with :-)
Replying to
(and there are so many of them that there's no possible way to condition them to the community's norms, hence eternal September)
this MSRC saga seems destined to be canonized as an almost flawless example of how to implode community trust in a security setting through entirely unforced errors
Replying to
@nedbat @hugovk these days I increasingly feel like it's impossible to do anything on GitHub without hitting a weird platform limitation like this one 🙂
I've filed https://github.com/dependabot/dependabot-core/issues/14713 for this on the Dependabot side
Replying to
@joshbressers @ancoghlan @hugovk it gets tricky when it's something that's contextually secure, e.g. http.server is secure under my attacker model when I'm running it on localhost, and I like that Python has it. but I'm sure the CPython folks are very tired of getting vuln reports for it!
Replying to
@andrewnez yeah pretty similar, although with hacktoberfest at least the point was (kind of) to attract those beginners. but same negative outcomes!
Replying to
@westonsteimel hmm, like something where zizmor warns you to always explicitly put permissions: {}, even if all jobs are already down-scoped? That’s something I’d consider adding as a pedantic or auditor finding to zizmor, but I’m not aware of anything else that does that
Replying to
@djc@hachyderm.io yeah, if one of your dependencies (transitive or not) places an upper bound. in practice this ends up not being a huge problem though, since Python packaging as a whole tends to be very good about compatibility.
(this does cause issues though! Pydantic v1 -> v2 was a pretty painful upgrade for a lot of people because every leaf's constraint of Pydantic also needed to be explicitly broadened)
Replying to
@SnoopJ@hachyderm.io @kojoidrissa@fosstodon.org I think the inconsistency is surprising, but IMO int() should actually do neither this nor other non-western-arabic numbering schemes! it's IMO a good example of two (eminently) reasonable concerns being mixed rather than properly isolated -- int() should turn non-formatted western arabic digits into numbers, and there should probably be an int.parse() or similar API that can handle different numeral systems, i18n, infixes, etc.
following PEP 833, Python packaging now considers the HTML index representation frozen!
I’m really happy we got this out: IMO it’s a small but very important step towards nudging clients to prefer the JSON index, which is better in every regard.
https://blog.pypi.org/posts/2026-08-11-html-index-is-frozen/
Replying to
@bagder@mastodon.social I think (hope) patch the planet will correct some of this: https://openai.com/index/patch-the-planet/
(I agree overall to be clear, Python's PSRT is very much swamped with reports.)
Replying to
@andrewnez true but I think we’ve only seen the beginning of it with bug reports/vuln spam. At least until the reputational incentives tail off
Replying to
@matmair my experiences with them (which have been relatively few) have been uniformly negative. I really don't understand why they occupy such a trusted position in the CVE/CNA system, given how little accountability they seem to be subject to. then again, my experience with MITRE is similar in terms of getting spam contested!
why tf am I a shower head
Replying to
@glyph@mastodon.social the main thing I’ve found them good for is information retrieval in other languages. But then you also get bangers like this
Replying to
(this is true regardless of the consumer. LLMs don't have mental states but you can still waste your money and sanity watching them chase down false leads.)
Replying to
@prioinv@hachyderm.io in principle nothing would break, but I think it would still be pretty exploitable in practice due to people granting elevated permissions to those jobs