Episode 4: Everything Python – Trusted Publishers & Authors – ActiveState Podcast

Welcome to episode four of the Act of State Podcast theories. Today it's episode four, everything Python, trusted Publishers and authors. Uh, Pete Garcin, director of product here at Act of State.

And joining me today is Jeremy Paige. Hello? Morning.

Yeah, I am Jeremy, page software engineer and Python specialist at Active State. So what we're gonna do today is just sort of dig into what's going on in the Python ecosystem and, and specifically we'll talk a little bit about the new Trusted publishing initiative, which is just recently been expanded and we've joined that, that cast of trusted publishers on Pi P. Why don't we start here, Jeremy, though, just talking a little bit about, maybe we'll just talk a little bit about what Trusted Publishing is and maybe even backing up about like why is it needed?

Sure. Yeah. I mean, as being part of this effort, trusted Publishing is basically a way to push packages to open internet repository without passwords and still get that same security.

So if you use a trusted entity such as Active States, we will do all the handshaking and signing and boring stuff for you so that your package just goes right into the cloud. Yeah, it's, I think that the need for this, I think that people maybe underestimate how risky it is to have those long, long lived passwords that you're sending around places and, and just what a big target the, the public repositories have become for different supply chain attacks. Right.

Yeah. And I think, I think this is right that before Trusted Publishing tokens weren't really scoped on pi. I know some other services you can get scoped permissions, but if you are Netflix, but you've only published some silly example project, but I get a hold of your token, I could publish a serious new package under your name and I can change your password.

You do whatever I want. Yeah, absolutely. I, I think that people were using their actual, their full passwords and I know that, uh, Pipi has done a few things recently enforced two factor, I think that came in pretty recently, where now everybody has to at least have two factor on there, but even still, you don't wanna be passing around those long-lived tokens.

So yeah, I think that that's one of the, one of the big benefits. I I think that there's some workflow benefits to you to, to having something like Trusted Publishing where before you were using something like Twine, possibly just manually from the command line for those who listening Twine is like a command line utility or interacting with PI PI for publishing packages. Anything else to say on that, Jeremy?

No. I mean, yeah, definitely Twine, it was still is pretty popular in this space, but it was another one of those decisions where we sort of have analysis paralysis and Python publishing where like, okay, you've gone through all the work of finding the Python version you wanna work with and you've figured out the build back and you wanna work with and you just discovered whether you wanna use Con or a PIP or active state and then you built your package and now you have to choose the tool to upload it. 'cause if you're using poetry, then use poetry to upload.

And if you're using set of tools to use Twine to upload, uh, and there are other options, you could just hit the API manually with the rest API. Right. So decisions and Trusted publishing generally tries to take away some of those choices from you in a good way.

Yeah, I think that it makes it so that you can have something that's more reproducible, maybe a little bit something that's a little bit more automated as well. Probably. I mean, you can obviously automate those other things as well, but in this way you can go, it cuts out one step as well, right?

Because you can go directly from whichever trusted publisher. If you're using GitHub, you're using active state GitLab, whatever, you can go directly from your CI environment essentially to pushing it directly to Pi p. It also opens the door down the road for, um, some enhancements that that can be made to, to the kind of information that gets stored on the public repositories.

So in a prior episode, Dana and I talked a little bit about different supply chain attacks and, and having provenance is something that I think is valuable. We wanna recap that here, but what, what, why is that important for us to know why, where something's coming from? Yeah, I mean I recap it here, uh, and that's a big part of trust publishing, but essentially it's more of an audit trail.

It's not this AI thing that's gonna come in warned you're about to be attacked. It's for postmortem, but it is very important because when something like Log four J comes along and you pretty much don't get to do any more business until you've finished that audit trail. Uh, so you can either go and do it yourself by having 158 GitHub tabs open in your web browser, or you can ask someone like Act State or just an sbo, which would be the software bill of materials.

Yeah, exactly. And I think that's even one of the things that we reviewed recently in the last, uh, webinar that we had, Dustin and I went over about how even on Pipi, if you publish with Trusted Publishing, it will show that this was uploaded by, by a trusted publisher there. But then even going further, being able to get, if you have a reproducible environment, then being able to get good provenance is important.

And I know that we talked, we also touched on this in the, in that webinar was that there's PEP seven 40 right now that is being reviewed. So for those who are not Python pap is a Python enhancement proposal or whatever. And this one is proposing that you could also publish, um, prominence information alongside your packages on, uh, pipis.

So that would allow you to be able to more accurately validate the trusted publishing is one step, right, where you can see, oh, this package was, you know, published via a trusted publisher. And you can look at the history tab and see that, see all the audit trail there that you're talking about, the sort of chain of custody. But then even moving forward, it sounds like they're going to be able to generate Providence alongside that.

Yeah, that's one thing that maybe we take for granted act of state is that just 'cause you just trusted publisher doesn't mean that you have Providence for your entire bill. Because again, there's a lot of steps to publish an in a package to Python, including building it and you can totally build your package offline with and whatever the heck was laying around in your system. And then trusted publish that.

Most of these systems you are actually building in the same system using a different job alongside the trusted publishing. But with ActiveState, we always build from source you and your dependencies. So without that, you don't really have the chain of custody.

You only have one layer of trusted publishing. And if you need to check your dependencies, you'd have to hope that they did trusted publishing, uh, or you're back into the sort of depth of get history or some, some other, uh, trail. Yeah, that's exactly right.

Because the sort of example that we used before was that you can, it could just be somebody publishing something they made on their laptop and they don't, they might not have really paid much attention to where they pulled down their dependencies from, which also could have been made on a laptop that's running whatever, versus something where it's built from source. And you have a verifiable way to know that all, everything that's included in here, we know where it came from, we know where it was built and where sort of where it's going. I think that, are there any things in terms of general sort of in the package ecosystem in the author ecosystem, is there anything else that, uh, is around any other benefits to being able to do use something like Trusted publishing?

Any other security things like Two Factor that we are aware of recently? Yeah. Well, Pipi did also in sort of related effort, but not entirely introduced orgs, which is kind of very slowly picking up.

But before that, there was really no way to verify where a package came from. I mean, packages on pi, I have authors and those authors are whatever name they signed up with, whether they were a personal developer who later went on to join Amazon or Google or a CTO who then left the company. Uh, there's no really way to track this.

But with Verified Publishing, uh, it is recorded at the exact address that the publish came from. So then that doesn't quite solve the problem. But if you trust, if you the third party developer trust that trusted publisher, then you can see, oh, this came from the GitHub profile that is linked with this company, or this came from Active State and I can go to their org.

Um, maybe it belongs to the company I'm at. Or not the one that says Dash for real. Yeah.

What is is is organizations like, uh, a mandatory feature these days or is optional and is there a way, do, is there a way to verify the organizations like you're saying, is there a way to differentiate the GitHub versus the GitHub dash for real? I mean, I'm not part of any organizations, so I don't, I don't know all those answers. It's definitely not mandatory.

Uh, and still, uh, from what I can see, the rollout is going slowly 'cause I think the orgs are being sham approved, which is maybe good news for security, but also results in a very long startup time to get all the orgs that we want up there. I don't think there's any sort of like web finger protocol or cert signing that guarantees these, but I could be wrong. Yeah, I don't know.

I'm also not a member of orgs on on Pipi, but I did, I do remember them announcing it and that this is a way to, to collect, I'm assuming that it works something like GI and that you can belong to a number of organizations and that these are ways to again, sort of manage credentials for, for a group of individuals along with this sort of credential changes that we're doing with, um, with uh, trusted Publishing and the two factor that's going on. I think that one of the other things is obviously, um, other risks of like account takeovers when we're talking about this kind of thing where if you, if somebody's gonna take over o over an account, that's going to potentially be a risk if you're using long lived credentials like Trusted Publishing had. The other thing is like obviously people committing their secrets to things like GitHub or having them baked into Docker images or things like that.

And I think that the move to sort of very short-lived tokens is very valuable. Do you wanna talk a little bit about how, how shortlived are the tokens for Trusted publishing? That's Bit of a hard question.

'cause as the trusted publisher, there's actually more than one token we have to deal with. And the progressively smaller, I, I think your use your active state off token is on the order of half a day or so where you can talk to your project that you are an owner of and then that gets a medium token of about an hour where we verify act of state with Pi Pie and then you, the publish job get another token of about a minute or five minutes or something to actually finish the, the sending your bits across the internet. Uh, if that doesn't work well, we'll pro progressively go back in order of the, of these certs and uh, try and get new ones for you.

But that the actual build should take place in a matter of about a minute, maybe, maybe four or five minutes and then it won't work anymore. Yeah, I think that's, I mean that having credentials on that really dramatically reduces the kind of attack surface there because, but the attack vectors, because it, you have to be know, you have to know when somebody's publishing and that this token is available within this five minute window, like you're saying, it's very, versus something that might be if it's commissioned to a hit repo or even if it's, even if it's configured in your environment kind of thing. Right.

It's some kind of, it's in an environment variable on a machine that's floating around, which is not uncommon. That might be set once and then forgotten about. Do you wanna talk about how Trusted Publishing came about?

It sounds like there was a uh, user survey from a couple years ago that drove both organizations and uh, trusted Publishing. Is that how it worked? Yeah, I know it did.

org who was able to push a lot of the ideas that have been floated by the community for a long time. But it takes funding sometimes to get them done. One of the first things they did was send a survey out to the general Python community, but they also reached out to some of us Python redistributors.

'cause we often have to deal with how things end up on Pi Pi whether good or bad. org and I think trust in Publish Trusted Publishing also came out of that and there are more good ideas, but there sort of ranked based on that survey. Yeah, I remembered that one of the ones that when we started looking at doing Trusted Publishing, one of the ones that jumped out was there was, I think it was listed as one of the fundable projects was a generic wheel building service for the community.

And I think there's a GitHub ticket for that that's still open. But our platform essentially, uh, active Safe Platform essentially performs that operation as a generic wheel building service where we're all kind of already ingesting everything from PI P and and building it from source and generating that from multiple platforms, any platform. So that was one of the, actually one of the initial triggers for us to approach working with PI P to say like, we're sort of already doing this.

Maybe there's some way we could partner here. And that's when we first learned about the, the idea that they were doing trusted publishing, we OIDC and also we had this conversation a little bit about Providence. That ultimately that, I mean that's something where we can help contribute in that way.

Once that's available as a thing on the eye, we will be able to generate uh, that kind of provenance on our platform. Yeah, I mean we already do. If if you come to us you can get that providence right now.

But we don't have a way yet to hand it to PI so that you can see it elsewhere. We are doing it now and we are making wheels for anything that comes outta the pipeline ecosystem right now. Sort of we'll lazily evaluate your wheel for you rather than you having to have 'em already.

And that's been a fundable project. The basically get more wheels on Pipi since before they had a PM since right when wheels were early. It's been a fundable project for a long time.

No one's really picked it up. Just mentioning real quick, it's still so important. Users 'cause a lot of time that the average Python person doesn't want to deal with, which is the kind of package that's not a wheel.

The other one diss require you running code on your system to install packages, which is not only in Attack Vector but it's slower and uh, has more chances of failure when you get a wheel. You can't fail because of a build 'cause there's no build could maybe fail to find distribution that matches you or you just, I don't know, you don't have permissions to install packages on your computer, but you can't fail because of a build. And so getting more wheels means less failures across the ecosystem.

Yeah. And I think that there are definitely maybe certain platforms that are better served for wheel coverage than others. And it's gonna probably depend a little bit on what's the popular system for developers.

Individual developers might not have access to the other hardware to verify does my wheel run on Mac Os or, or whatever, right. They might only be running a a Linux box or something like that. I mean, I dunno anyone who both builds and tests wheels or really any package on multiple platforms that is doing it locally isn't doing without help with some sort of CI process.

If you do a ci that's an investment that's 200 lines of YAML that you might not understand. You're just cribbing from someone else. Yeah, yeah, exactly.

And there's a lot of plumbing to get all that stuff to work, right, to stitch it all together to get, to get your code into the CI to get it, to build, get it, to build the wheels, to deploy it to the server. There's a lot, there's a lot of pieces moving parts there. Yeah.

Trusted publishing obviously removes at least one of those moving parts essentially, Right? And you still need to build system. Yeah, you still need to build systems.

But that's where I think that, I think that if you're a Python author and you're listening to this, it's definitely worth checking out active safe platform to, to build your wheels, to even manage your dependencies to work, work on during development. You can use our platform to, to track all the dependencies, make sure it's all perfectly reproducible, and then hook directly into the trusted publishing and be able to publish, publish your package directly to, to Pipi. And it's even set up that you can publish to your, our catalog before it goes to Pipi.

So even when you're in development and it hasn't already been, you don't have something published on pipi that's maybe just an sist or something that you can work with it directly in our catalog. Very true. com and get a free account and try all this stuff out and the instructions for how to get started with the trusted publishing or on our website as well.

And we're gonna have a few more episodes in this active state podcast series. So yeah, Jeremy, it's been a pleasure chatting today and we'll see everyone next time. Bye.