Security, UX, and Sustainability For The Python Package Index - Episode 225

Summary

PyPI is a core component of the Python ecosystem that most developer’s have interacted with as either a producer or a consumer. But have you ever thought deeply about how it is implemented, who designs those interactions, and how it is secured? In this episode Nicole Harris and William Woodruff discuss their recent work to add new security capabilities and improve the overall accessibility and user experience. It is a worthwhile exercise to consider how much effort goes into making sure that we don’t have to think much about this piece of infrastructure that we all rely on.

linode-banner-sponsor-largeDo you want to try out some of the tools and applications that you heard about on Podcast.__init__? Do you have a side project that you want to share with the world? Check out Linode at linode.com/podcastinit or use the code podcastinit2019 and get a $20 credit to try out their fast and reliable Linux virtual servers. They’ve got lightning fast networking and SSD servers with plenty of power and storage to run whatever you want to experiment on.



Announcements

  • Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
  • When you’re ready to launch your next app or want to try a project you hear about on the show, you’ll need somewhere to deploy it, so take a look at our friends over at Linode. With 200 Gbit/s private networking, scalable shared block storage, node balancers, and a 40 Gbit/s public network, all controlled by a brand new API you’ve got everything you need to scale up. And for your tasks that need fast computation, such as training machine learning models, they just launched dedicated CPU instances. Go to pythonpodcast.com/linode to get a $20 credit and launch a new server in under a minute. And don’t forget to thank them for their continued support of this show!
  • You listen to this show to learn and stay up to date with the ways that Python is being used, including the latest in machine learning and data analysis. For even more opportunities to meet, listen, and learn from your peers you don’t want to miss out on this year’s conference season. We have partnered with organizations such as O’Reilly Media, Dataversity, Corinium Global Intelligence, and Data Counsil. Upcoming events include the O’Reilly AI conference, the Strata Data conference, the combined events of the Data Architecture Summit and Graphorum, and Data Council in Barcelona. Go to pythonpodcast.com/conferences to learn more about these and other events, and take advantage of our partner discounts to save money when you register today.
  • Visit the site to subscribe to the show, sign up for the newsletter, and read the show notes. And if you have any questions, comments, or suggestions I would love to hear them. You can reach me on Twitter at @Podcast__init__ or email [email protected])
  • To help other people find the show please leave a review on iTunes and tell your friends and co-workers
  • Join the community in the new Zulip chat workspace at pythonpodcast.com/chat
  • Your host as usual is Tobias Macey and today I’m interviewing Nicole Harris and William Woodruff about the work they are doing on the PyPI service to improve the security and utility of the package repository that we all rely on

Interview

  • Introductions
  • How did you get introduced to Python?
  • Can you start by sharing how you each got involved in working on PyPI?
    • What was the state of the system at the time that you first began working on it?
  • Once you committed to working on PyPI how did you each approach the process of identifying and prioritizing the work that needed to be done?
    • What were the most significant issues that you were faced with at the outset?
  • How often have the issues that you each focused on overlapped at the cross section of UX and security?
    • How do you balance the tradeoffs that exist at that boundary?
  • What is the surface area of the domains that you are each working in? (e.g. web UI, system API, data integrity, platform support, etc.)
    • What are some of the pain points or areas of confusion from a user perspective that you have dealt with in the process of improving the platform?
  • What have been the most notable features or improvements that you have each introduced to PyPI?
    • What were the biggest challenges with implementing or integrating those changes?
  • How do you approach introducing changes to PyPI given the volume of traffic that it needs to support and the level of importance that it serves in the community?
  • What are some examples of attack vectors that exist as a result of the nature of the PyPI platform and what are you most concerned by?
  • How does poor accessibility or user experience impact the utility of PyPI and the community members who interact with it?
  • What have you found to be the most interesting/challenging/unexpected aspects of working on Warehouse?
    • What are some of the most useful lessons that you have learned in the process?
  • What do you have planned for future improvements to the platform?
    • How can the listeners get involved and help out?
  • How was this work funded?

Keep In Touch

  • Nicole
    • @nlhkabu on Twitter
    • Website
    • If you’re using CI to upload to PyPI and would like to speak with Nicole please book a time here
    • If you’re using assistive technology and would like to speak with Nicole please book a time here
  • William
    • @8x5clPW2
    • Website
    • Email
    • Please get in touch if you’d like to work with Trail of Bits on your next security project!

Picks

Links

The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA

Click here to read the raw transcript...
Tobias Macey
0:00:13
Hello, and welcome to podcast, the podcast about Python and the people who make it great. When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So take a look at our friends over at Lenovo with 200 gigabit private networking, scalable shared block storage, node balancers, and a 40 gigabit public network all controlled by a brand new API, you've got everything you need to scale up. And for your tasks that need fast computations, such as training machine learning models and running your ci CD pipelines. They just launched dedicated CPU instances. They've also got worldwide data centers, including a new one in Toronto and one opening in Mumbai at the end of the year. So go to Python podcast.com slash Linux that's LINOD today to get a $20 credit and launch a new server and under a minute, and don't forget to thank them for their continued support of this show. For even more opportunities to meet, listen and learn from your peers. You don't want to miss out on this year's conference season. We have partnered with organizations such as O'Reilly Media Day diversity and the Open Data Science Conference with upcoming events including the O'Reilly AI conference, the strata data conference, and to the combined events of the data architecture summit and graph forum, go to Python podcast.com slash conferences to learn more and to take advantage of our partner discounts when you register. Your host, as usual is Tobias Macey. And today I'm interviewing Nicole Harris and William Woodruff about the work they are doing on the Pi Pi service to improve the security and utility of the package repository that we all rely on. So Nicole, can you start by introducing yourself?
Nicole Harris
0:01:38
Yeah. Hi, my name is Nicole Harris. I've been working on ipi or the warehouse project, which is the code base that powers API for about three or four years now. In my day job, I manage a UX UI team at a company called peopledoc. But in my spare time I work on po po.
Tobias Macey
0:02:00
William, can you introduce yourself?
William Woodruff
0:02:02
Sure. So my name is William Woodruff. I'm a security engineer with a small security consultancy called trilobites. I've actually been working on warehouse for only about five or six months now we started the work back in March. But during my day job, I sort of split my time between engineering and research. And on the research side, I do program analysis, research, mostly government funded. On the engineering side, I work on mostly open source projects, like warehouse, and always Korea and things like that.
Tobias Macey
0:02:30
And going back to you, Nicole, do you remember how you first got introduced to Python.
Nicole Harris
0:02:33
So my background is in HTML, CSS design user interface. So I, Python wasn't sort of the first technology that I was exposed to in terms of the web. But my husband is actually a Python developer, he started teaching himself programming by learning Django. So through him, basically, I got introduced to Python, and also learned, you know, and not enough Python to be useful alongside my friend and skills.
Tobias Macey
0:03:06
And William, do you remember how you first got introduced to Python? I think
William Woodruff
0:03:09
I think I use Python and a few university courses, but I didn't actually really start programming in earnest at it until I took this job. And before that, I also did actually CM Ruby. So this has been sort of a nice, a nice turn for me.
Tobias Macey
0:03:26
And given the fact that you haven't been using it for your day to day, I'm curious how much effort it's been to get up to speed with the code base, and be able to understand it and be effective with it. And how much of your experience with Ruby in particular was able to easily translate?
William Woodruff
0:03:43
Oh, so I think Fortunately, the warehouse code base, I'd like to say, it's probably one of the nicest Python code bases I've worked on. It has like 100% unit test coverage. And the idioms of the frameworks that it uses are actually well preserved across the code base. So it was actually relatively easy to get up to speed. And thankfully, I had both Nicole and everybody over on the PSL side, as well as to Minaj gene set to answer my questions as as they came up.
Tobias Macey
0:04:11
And so for both of you, I'm wondering if you can just start by sharing a bit about how you each got involved in working on the pipeline project and the main responsibilities that you have.
Nicole Harris
0:04:24
Yeah, so I can maybe start there. So I think it must have been in 2015, Donald stuffed, who is the lead developer on on warehouse, which is the project pairing pi pi, sent out, I think he actually opened a GitHub ticket that said, help, I need a designer, this is not something that I'm good at, you know, I'm rebuilding this thing. And, you know, this is completely outside of my skill set. So, you know, please retweet. And it was through one of my friends that had actually met at a party unconference that I that I kind of put my hand up and said, Hi, you know, I'm Nicole, and this is, this is what I do, and, and I think I can help you so. So that's how I got involved in in my, my involvement has kind of extended from there. So in terms of my responsibilities, I'm responsible for the UX, the UI, so the user experience user interface, as well as the HTML and CSS code base for the warehouse project. So a bit of a bit of coding and a bit of designing.
Tobias Macey
0:05:36
And William, How about yourself?
William Woodruff
0:05:37
Yeah. So on my side, I got involved by the current contract that I'm working on, which is the OTF funded security improvements to warehouse. And my work is primarily revolved around four key changes to the warehouse code base to sort of improve both the way that users improve the ability for users to secure their accounts, as well as improve the general security posture of the bypass base. And I can talk about the specifics of those improvements as we go forward. But uh, that was, that was how I got started.
Tobias Macey
0:06:06
And particularly for a unicorn, what was the state of the system at the time that you first began working on it, and any of the notable issues that you were first faced with?
Nicole Harris
0:06:17
So I didn't know if you're aware of the sort of full history of pi VI, the, when I joined the project in I think it was 2015 2016. Basically, api.org was still powered by an old code base that had been written like, I think it had been written before kind of web frameworks even existed. I think, I think Donal described it as before we even knew how to like use Python to, to build great web experiences. So in terms of the the state of the ecosystem, you know, there was this old code base, that I was kind of that the tunneled really discouraged me from diving into, he was like, Look, don't look at it, it's no best practice. What we're going to do is we're going to rebuild this from scratch. So you know, I had a fairly clean slate in terms of the user interface. And in fact, the HTML and the CSS code base, Donald did have some sort of, I think, the bootstrap templates that were working in the code base, but they weren't particularly finessed, let's see the whole basically just kind of out putting data onto the screen. So I basically rebuilt that from scratch, and made a whole lot of decisions about how we were going to structure not so much the templates, but certainly the the CSS because we were using SAS, yes, CSS code base, so that it would be something that would be easy to maintain moving forward. Because if any of your listeners have experienced sort of working on large code bases with CSS, it can get out of control pretty quickly. So we needed to put that in from the beginning.
William Woodruff
0:08:01
Yeah, so as I started working on warehouse, one of the first things I looked at was sort of the present security posture of the site and of the various like, sort of common weak points and package management, such as like name squatting, or project name, reuse, or username reuse. And overall, as far as package managers and packaging dependencies go, warehouse was in a pretty good state. So for example, as I began working, already supported, preventing common type of squatting attacks on packages, and it had written limiters and other sort of mechanisms in place to prevent these really common low level attacks against package indices. The things that I ended up working on as part of the OTF funded scope were things that are sort of above and beyond the current norm for for package indices. And that would be like, two factor authentication API tokens, surprisingly, are not the norm for prepackaged indices, and the logging infrastructure.
Tobias Macey
0:09:01
And will I understand that you have also worked on the homebrew package manager as well. And I'm wondering what your initial reactions were, as you started digging into warehouse and how it compared to your prior experience of working with other package managers and some of the common security pitfalls that are germane to that particular type of application.
William Woodruff
0:09:22
I will say I'm probably the homers current worst maintainer, I'm probably one of the least active ones. But the the security issues that Humber has to deal with are somewhat unfortunately, somewhat orthogonal to traditional homebrew, or traditional package management issues, primarily because homebrew revolves around this the central repository for all packages. And so we actually have finer grained control over both the integrity of packages as well as their origin, because we can actually see the get committed, as well as run like CI checks, basically, literally, as every package is updated. So it's all good. It's all good centralized in a way that, for example, by vi can't necessarily can't necessarily do. But that That being said,
Tobias Macey
0:10:06
I think, and so for each of you, once you began working on the Pi Pi code base, and working toward some of the initial issues, I'm curious if the problems that you were addressing are identified ahead of time or what your overall approach was for determining what were the most critical and most important tasks to be undertaking to improve the overall security and user experience of the platform.
Nicole Harris
0:10:35
So I can take this one, I think this this kind of relates to the way that this project has actually been funded. So as well as being a contributing designer slash developer on on pi pi. I'm also a member of the Python packaging Working Group, which is the sort of sub organization or working group that that works under the Python Software Foundation to raise money for packaging related projects. And it was through that working group that we actually got funding to make the security improvements that the users are starting to see being rolled out on pi pi. So the scope of the work that will and I have been undertaking is is directly related to the application that we made to the open technology fund who have actually funded this work. So what we did is we, we looked at their their mission and their vision and their values, we looked at the different grants streams, and we made an application for the items that we thought were relevant to their particular fund. And that was kind of what determines the scope of everything that has been funded through that particular initiative. So I think will you probably agree that in coming into this project, we had fairly well defined parameters around what was and what wasn't in scope based on what was basically being funded and what we'd what we said we were going to do.
William Woodruff
0:12:02
Yeah, I think that's correct. I think, yeah, we had a we had a high level idea of the individual goals we want to achieve based on the work that we scoped out with IVF. And then once we actually began work, we sort of prioritized the individual tasks based on what we thought would have both the highest user impact as well as what we could roll out with, with like minimal, minimal disruption to like, I think, like package upload and the user experience.
Tobias Macey
0:12:28
And given that you're both focusing on somewhat different areas of the platform, I'm wondering how often the issues that you're focusing on have had overlap, and what the cross section ends up being between user experience and security, particularly given that the interfaces that you're dealing with aren't necessarily just the web UI that you see when you load up the web page.
William Woodruff
0:12:52
So I actually I'm of the opinion that like, UI is severely underrated in terms of user security. So users, oftentimes, our don't know how to don't really know how to engage with the security features that security engineers exposed to them. And this is an issue that I've run into and other platforms that I've worked on. And I think a huge part a huge, huge boon to working with, Nicole has been actually setting up a set of features and then seeing how how to expose them correctly to users set up something that I'm not personally equipped to do. And seeing her build like this actually extremely pleasant to use, and extremely intuitive. Setup has been really great.
Tobias Macey
0:13:34
And then in terms of the trade offs that exist, I know that oftentimes there's a conflict between improving the overall security of a system but also still making it usable, because as you ratchet down too tightly on making something ultimately secure, you start to encourage people to take shortcuts that ultimately reduces the effectiveness of your practices and how you try to balance that issue and some of the common patterns that you have settled on to make sure that you're improving the security as much as possible, while still making sure that people are adhering by the security practices.
William Woodruff
0:14:12
Yeah, I think a huge challenge when designing secure systems is is security fatigue. So one of the last things you want to do is, like I said, ratchet down the system so much that users become frustrated and take shortcuts to achieve achieve their ends. And that's one of the issues you often see with a two factor implementations as a two factor implementation will, like require a user to sign on or re authenticate so frequently, that users will just like move there to TP setup on to their post itself and just control C Control V and thereby like dissolve the second factor component of the authentication scheme.
Tobias Macey
0:14:46
and wondering too, if you can just enumerate the overall list of interfaces. And the total surface area of the problems that you're each working with, as far as the special is a mix of the API project, because with some projects that might be limited to just the web UI, others it might be just an API. But with API, there's the web interface there the API's that users are using those the actual data integrity, as well as the actual interactions that people have of downloading and installing the packages, which is potentially another attack vector that isn't necessarily going to be present in other projects.
William Woodruff
0:15:25
Yeah, I think so the work that, at least what I did the work that I did, primarily centered around the API and the web interface. So the security features that we added specifically two factor authentication, API tokens, and an audit log of those two factor authentication is is intended primarily for use with the web interface, and audit log. Visibility is performed via the web interface, although some online events are actually captured as the user hits the API for like, two sensitive actions, such as package uploads, or file uploads, or removals. But also on the API side, there's API tokens themselves, which the user will interact with, via a tool like setup tools, or twine, or any of the other clients that interact with the warehouse API.
Tobias Macey
0:16:16
And, Nicole for you, as well. I'm wondering what the surface areas that you're dealing with as far as the user experience work, and some of the ways that that manifests at the different trade offs and the interactions between API's and web UI, and the overall package upload experience, etc.
Nicole Harris
0:16:36
Yeah, so I mean, in terms of this current contract, my work has been limited to basically what we'll just described. So first part was making sure that when users that they find it easy to set up two factor authentication, and then to use that out when logging into pi pi.org. So that's sort of the first first thing we worked on. Then we looked at the, the API keys. So sorry, API tokens, we're avoiding the word keys. And I can tell you why later. But looking at how it's, it's, you know, making it easy for users to set up those those tokens. And then obviously, as will set as well, exposing the audit log to the end users in terms of my work with regards to sort of the way that people interact with pi pi outside the browser, that's really limited to me, making sure that the instructional texts and the help texts that were showing on pi pi.org is actually useful enough for people to be able to do what they need to do. So for example, with the API tokens that were we've just deployed, I've been running some user tests that have revealed that perhaps the the way that we display the token, and the instructions that we give to users currently is not good enough for them to understand what they need to do next, using using whatever tool they're using. So that's kind of where my sphere of influence kind of sits is making sure that people have the information that they need to be able to then interact with API. However they need to do that.
Tobias Macey
0:18:28
That I'm sure is also complicated by the fact that there are any number of different tools that people might be using that would require the access to that API token, where I know that there's Pip. And there's twine for being able to upload things and flit and there are, I'm sure any number of different homegrown applications, and I'm wondering how that plays into your efforts to make sure that the instructions are clear and accessible. And I guess how far you're willing to take the effort. And when you decide that you covered enough ground, and the sort of majority of people are handled, and anybody who is in some of these edge cases is there because of something that they've decided to do that isn't necessarily something that would be required to be supported by the people responsible for the API infrastructure?
Nicole Harris
0:19:16
Yeah, I think I think there's sort of to two factors when, when thinking about, or at least how I think about designing for pi phi, it's, it's that yet people have different workflows, as you've just described, and also that you have people with different really vastly different levels of knowledge as well. So, you know, Python is now being used a lot, as a teaching language. So I'm really aware that pi pi could be the first, you know, package index that some people are using or experiencing. So they might not be familiar with all of the concepts that we present to them. On the flip side, you have people who've been coding, you know, decades, and a really familiar with all the concepts. So it's a real challenge in terms of making sure that you're explaining things enough for beginners, whilst also not sort of, you know, talking down to people who are who are really experienced. So that so that is, that is a challenge, but I tend to lean on the side of, Okay, let's, let's give more information for beginners, because at the end of the day, experienced users can ignore instructions that they already know if they don't need them in terms of the kind of weighing up or how much information to give, which tend to take a lot of feedback from the community. So I mean, I've run user tests and thinking more less about the API tokens here and more about the two factor authentication workflow that we worked on, I ran a whole lot of user tests, when we were rolling out those interfaces, with people with different levels of experience, and who were who had different, we're kind of using different tools, you know, for example, to for to TP to authenticate that some people will using a password manager to create a temporary one time password word. Some people using mobile phone, though, using all three other people, you know, there was all sorts of different ways that people were doing that and and what we in the end did was put a whole lot of examples into our text of, Okay, these are the kind of the kind of applications that you might choose to use. And we made sure that we had a good balance there between, you know, sort of the most popular tools. So things like Google Authenticator and author sort of floated to the top of the list as as things that people sort of were mentioning frequently, but also mentioning, you know, the kind of less common use cases making sure, for example, that we were listing non proprietary solutions as well, because we know that there's members of the community out there who prefer not to use proprietary software. So it it's really just about prioritizing the way that you present the information to cover the most common use case first, and then give the kind of the information for the edge cases later. Yeah, and I would say that's the same. Also, when we're talking about webauthn, which is two factor authentication with some kind of device. Lots of people understand that as OI authenticate with a yubikey. Because you know, yubikey is probably the most popular, the most popular USB key that you can use with that particular standard. But we do have people out there in the community who are using other things. So what we ended up doing was writing the instructional and the help text in such a way to sort of emphasize USB keys mentioning certain brand names. So people kind of were associating what we were talking about with the correct concept. And then also mentioning, hey, there's all these other ways that you can also do this as well, by the way. So I think that balance is quite good. Because generally, generally, if you are not necessarily using the most mainstream, as you sort of said, if you're not using the most mainstream solution out there on the market, then you're probably more familiar and more advanced use it anyway. In which case, perhaps the help Texas or the instructional text is less required for you than it might be for someone who's a beginner who's using something that's fairly mainstream.
William Woodruff
0:23:28
Yeah. And to add on to that for the API tokens work we did. One thing that's pretty interesting about the Python package ecosystem as a whole is that there's a whole lot of third party clients out there and a whole lot of third party implementations that talk to these API's. And so as we were designing out the initial API keys approach, we realized that we would probably have to make concessions in terms of like authentication semantics to make them fit into all of these third party clients that expect a username and password instead of just a general purpose key authentication. As we're working on that, we also realized very quickly that the range in continuous integration setups as well as other automated systems, constrained our ability to add certain token prefixes and certain sub usernames. So doing all that work was was pretty interesting because it involved community feedback, as well as trying to sort of guests common or happy paths and unhappy paths for for common for common uses of tokens, or sorry, API keys.
Nicole Harris
0:24:26
One thing I'd also like to add to that is, I don't know when this podcast exactly is going to go out. But I'm currently in terms of those API API tokens, I'm still working on improving the help text in the instructional text. But I do need to seek feedback from from members of the community as to what tools they are using their API tokens with so that I can make sure that I am covering all of those, well, as many of those use cases as possible within the help and instructional tech. So I suppose that's a bit of a call to action. And I know, we'll probably get a chance to make another one by the end of this podcast. But if you're a community member out there, and you're particularly particularly interested in if you're using a continuous integration service to upload your package to pi pi, and you'd like to test out the API tokens, and I'd really like to speak to you because understanding what your workflow is, and how we can document that in the user interface and give brief but useful instructions would be very valuable.
Tobias Macey
0:25:32
As we've been discussing here, there is a wide variety of people and patterns in terms of how the API infrastructure is interacted with. And I'm curious how that informs and affects your overall workflow and strategy for interior for introducing changes to the platform, and how you validate and I guess, control the rollout of those changes.
Nicole Harris
0:26:00
Yeah, so I can speak on that a little bit. So in terms of releasing new features, well, a lot of this is actually handed base, similar from chain sick consulting, who's our project manager for this contract, and she's worked as a project manager for previous contracts as well. And in what she does is she reaches out to the community and does a lot of communication about what the upcoming features are going to be within, when we release a new feature, it's marked as a beta or beta, depending on your accent, feature. So it sort of comes with the warning of you know, this is something that we've shipped, but you know, it's it's, it's still not kind of certified as as as perfect and, and production ready. So you know, obviously set things up with the expectation that perhaps things might change. And she does communication at that point as well to reach out to the community to say, Hey, we really this new thing, please go and test it. At that stage. I obviously also do some reach out in terms of user testing with people to see if they've got any any problems, working through the interfaces, but we also because of her work in in sort of communicating what's going on to the wider community, we do tend to get a lot of tickets opened up on on GitHub, where people said, Hey, you know, I've tried out this thing, and it's not quite working, you know, there's a bug you or I'm using a browser that you haven't tested it with, or whatever it is, and then we go and address those, those particular issues before we can obviously move out of the beta period. So so it's been quite smooth so far, in terms of, you know, yeah, there's bugs. But we expect that to happen within that period. And we've been quite good at turning around and fixing those. And, and because we're labeling things as beta, people under stand at that that's, you know, part of the process of developing software. Will did you want to comment on that at all, in terms of some of the changes maybe that we've had to make based on on feedback that's come back from the community?
William Woodruff
0:28:11
Yeah. So I think the the big things that come to mind are what you mentioned earlier with, with confusion about token versus key in the context of security token versus what I originally called API tokens, but we quickly realized confuses users because they associate token with with a physical device. We've also on the on more of the development side. I think I mentioned earlier, but warehouse has pretty comprehensive unit tests. So as as we've been developing, we've been somewhat fortunate to catch things that otherwise probably would have, would have blown up in production. As both unit tests and as as sort of smoke tests by either seminar or the reviewers on the PSF. side, that would be earnest, Donald and Dustin.
Tobias Macey
0:28:56
So we've mentioned the API key, and some of the two factor off features that have been introduced. I'm curious, what have been some of the other notable features or improvements that you've been involved with?
Nicole Harris
0:29:09
Well, I suppose I've been involved in since very early. So I'm going to scope my answer to that question to this particular contract, which is the RTF contract. So yeah, as you said, two factor authentication API, API token. And then the audit log, which is basically being able to expose so that with this kind of, from my point of view, there's two sides to that audit log, it's, we have an account audit log. So when you log into your account, you can see, okay, you know, when did I last change my password? When did I set up an API key, when did I enable two factor authentication, etc, etc. So we've got that exposed. And then we've also got project audit logs as well. So things that have happened on an individual project. So for example, a new release has been made or, or an API key has been created that has permissions on this project. So things like that. The other thing to mention is that the ETFs grant doesn't just cover security, when we made the application through the Python packaging working group, we also received funding to improve both the accessibility and the localization of pi pi.org, as well. So some of my work well, already working on this, but it's going to be my work moving forward as well, is to improve the accessibility of IPOs or for people who are using assistive technologies. So for example, people who are using screen readers or people who are limited to just using their keyboard, people who are using high contrast mode, etc. And also we're going to be implementing localization. So making it possible for us to translate at least the interface copy on popi eyes or org into a local languages, so French, Chinese, whatever, whatever community contributions we get for translations, those things are kind of within the scope of the ETFs contract as well. So that's super exciting, because it's not just about thinking about how we can make the site more secure. But also how can we make it more universally accessible for people who have different needs, and who are who are in in different communities, Python communities around the world.
Tobias Macey
0:31:36
And William, in terms of the attack vectors that you have considered for pipe E, I know that you said in general, it was in a fairly good security stance as far as already having some capacity for mitigating type of squatting attacks. But I'm wondering if there are some of the other attack vectors that you have looked at or other things that you're concerned and about for API, recognizing that you're not asking you to do any sort of improper disclosure, but just in general, some of the thoughts that you have as far as security and attack vectors for packet repository, I'm sure.
William Woodruff
0:32:14
So so the really common attack vectors that you see on package indices, and package managers are sort of those type of squatting, package takeover fishing based attacks, where someone will try to take over the account or add themselves as as a contributor to a project and then push up a malicious version of that project that contains, you know, a malware dropper, or whatever, whatever it needs to be. And I said, So fortunately, pipe I already had a few pretty pretty good medications in place, including for type of squatting and and rate limiting to prevent credential, brute forcing, there are some things that are sort of already well known, well known weaknesses in pipe is set up, those include sort of the way that that roles are currently structured. So at the moment, any account can be added to any project as an owner without that other project without that targeted users consent. So and and prior to this audit, login, without a ton of history, or login, to designate that, that change. So there are there are big issues with sort of transparency and package ownership, as well as transparency and changes in package control. So like it's, it's, if you I think, I'm actually not positive about this. But I believe currently, if you delete your project name on, if you delete your project on patreon.org, another user can claim that that name, and if that happens, you can then imagine a sort of package reuse attack where a popular package gets deleted by an attacker, and then they become a like, innocence legitimate owner, because they've actually claimed the project rather than taking it over.
Nicole Harris
0:33:49
Yeah, that's correct as To my knowledge, will, however, they can't release any files that have previously the being released, if that makes sense. So it would only be new versions moving forward. But you're right in in the sense that, yeah, it would be they would own the package. And have the legitimacy of of that that package name. With regards to your first comment, I know that we do have a pull request in progress, I'm hoping that we'll be able to address the issue with giving permission to add collaborators. Soon.
William Woodruff
0:34:29
Yeah. There's also the sort of more general problem of active scanning of projects for rather packages as they get uploaded. And that's I think, as far as I know, an unsolved problem in the world of package maintenance. And I don't think it's something that I could barely be asked to solve.
Nicole Harris
0:34:45
Well, what do you mean by that? He said, active scanning.
William Woodruff
0:34:47
Yeah. So imagine scanning for, like common indicators of compromise, or common indicators that have packages is malicious. For some for some, you know, fuzzy definition of malicious? Because you can imagine, like a recent package that contains malware samples, or what have you.
Tobias Macey
0:35:05
And particularly given the flexibility of Python and the ability to obfuscate the actual intent of the code, it's definitely a non trivial and potentially NP complete problem to be able to actually definitively to determine whether or not a package is malicious or has nefarious intent.
William Woodruff
0:35:24
Yeah, this is the problem with that some of the most lockdown platforms in the world struggle with, you know, Apple with their app store struggle with static analysis immensely. So I think it would be completely unreasonable to expect a dynamic language on a community maintained index to solve this problem.
Tobias Macey
0:35:40
So in terms of your overall experience of working on and with the Pi Pi platform, and the community of users who rely on it, what have been some of the most interesting or challenging or unexpected aspects of that work,
William Woodruff
0:35:55
I can try answering that. So on my at least, I've done community management before. Some of it as in my role, as I'm reminded, and or some of it on my own open source projects, as well as the open source work that trilobites does. But it is it is different every time. And so especially when dealing with feature changes that affect potentially 10s of thousands of people, it can be sort of challenging to get people to see your side of things, especially when it comes to like event logs. So very understandably, users are wary of any sort of feature that records their IP address for records, security, salient events, about their actions. And so it can be difficult to explain to users who don't necessarily see the value of those recordings, from a security perspective, it can be difficult to justify those events to them, and coming up with a compromise where we both get actionable, or were able to record enough information to take action, while also preserving their privacy and mitigating their concerns can be can be a challenge. Especially you know, for for countries where GDPR compliance is is key.
Nicole Harris
0:37:05
I think on my side, one of the issues with doing design in the open on open source community projects is that the work is very, very visible. And it's it is really hard to satisfy everybody, you know, everybody's using different browsers, everybody has different use cases. And, and, you know, we don't have any full time resources on, on looking at the user experience of pi pi, it's just me, and the hours that I have, either in my spare time when I'm working as a volunteer or as on this contract for my contracted hours. So, you know, it's, it has been challenging to try and satisfy everyone and, and make everybody happy. That was probably more challenging when we had the transition from the old api.org. Sorry, the old API code base to popular org, when there were a lot of changes, which was disruptive to people's existing workflows. On the other hand, there are a lot of people who are like, Yay, pipe eyes sort of moved into the modern era, and it works on mobile. And, and you know, so there's kind of two sides to every coin. What I've tried to do in terms of my work with pi pi, is make sure that when decisions are made, that they're really backed by either user research or user feedback, or by user testing. So you know, it not just being a case of me saying, well, it's my opinion that it should be like this, and therefore, my opinion, is most important. But actually being able to show people I looked into this, I looked at prior art, or I looked at, I spoke to people within the community, and this is the reason that this decision has been made. And when you actually articulate the reason and you show people that you've, you've thought about this more than just, you know, this is my opinion, then people are really responsive to that. So I think that that's been quite positive experience for me in in interacting with the Python community, who as a whole, very friendly, friendly bunch of people
Tobias Macey
0:39:15
in terms of the future work that you either have planned for your existing contract, or that you have identified as potential improvements to the platform in general, what do you think are most interesting or most notable? And what are some of the ways that listeners and the broader community can get involved and help out with your efforts and just the overall work needed to keep the pipeline platform healthy and viable for the long run,
Nicole Harris
0:39:45
so I can address that in terms of the current contract, most of the security work is is kind of done. Now. I mean, there's a few things that we need to wrap up. And as I mentioned, I would really like to talk to anybody who's using see is uploaded to it to pi pi, because that would be really helpful for me in terms of making sure that the interface is working for those use cases. In terms of the rest of this contract. As I mentioned earlier, we have accessibility and localization, which is the last two subjects that we need to address. In terms of accessibility, I've also put a call out recently, I'd really like to talk to any members of the Python community who are interacting with websites, and using assistive technologies. So if you're a user, who's online using a screen reader, I would love to speak to you. Same for if you're someone who's limited to using a keyboard, or if you're using high contrast mode. Or if you're using like a very zoomed in version, you know, you're using, you're zooming in your browser a lot because of poor eyesight. The reason that I would really like to speak to people who are using the web in those ways is because we're doing an audit against WCAG. Two point O standards, which is is kind of the accessibility standard. But just being able to tick the box isn't in my view enough, I mean, obviously, we want to check the box and say, yes, we're compliant. But actually being able to test the interface with people who are using a system assistive technology. And and seeing that it's working for them in in real life with real life use cases is super important, as well. So it's not really enough just to check the boxes, we really need to talk to people about how they're using the site as well. And on the localization side, and I think there'll be more communication that will come out about this later, as we sort of get into that milestone, we are going to be looking for people to help us to actually translate the interface copy into different languages. So once we've actually got the technical implementation done, you know, we're going to want to get people to translate it into whatever language that they'd like to translate it into barring Arabic and Hebrew and any right to left languages, because that is outside the scope of the current project.
William Woodruff
0:42:15
Yeah, I'm also on on the security side of things. There are things that are out of scope of the current contract, but that I believe, are planned for a future iteration on on the warehouse code base. And that would be things like, for API keys, the implementation that we went with, is based on the security tokens called macaroons. And one of the interesting things about macaroons is that they have embedded in them something called caveat language, which allows for a sort of rich description of the permissions associated with each token. And currently, we have a version of version field in our cabinet language that allows for those permissions to be iterated on, and modified to allow for sort of really rich interactions with the authentication system. So you can imagine, I think the future in the future, the plan is to add tokens that expire after exactly one use, or are only allowed between certain hours today, or can only be used from a certain domain in terms of or certain authenticated IP, or things like that. So I think we've put out on the warehouse issue tracker, sort of a request for for help with that
Nicole Harris
0:43:16
yet, I should mention here as well that if any of your listeners are interested in contributing to the warehouse project, the issue tracker is in in fairly good school fairly well managed. So we do tag issues with needs discussion or help required. So going on to the issue tracker, and having a look at what discussions are happening is kind of a useful way of being able to find out where you could help make pie pie more sustainable. In terms of the feature development that we're currently working on. The other thing I'd like to mention as well is that and I think what will already said today kind of reinforces this, it's a really nice code base to work on, like, pretty easy to set up with Docker and Docker compose, got really great unit test coverage, it really is a very nice code base to work on. So you know, if you're looking to make an open source contribution, I think it's a it's a good candidate. And we do welcome also, people who are making their first contribution to open source as well. So it's not just your more experienced listeners, you can make contributions to the warehouse code base, you have plenty of tickets tagged with good first issue, which, specifically for people who are looking to make sort of more mine now sort of to ease their way into open source contributions.
William Woodruff
0:44:43
Yeah, I do want to hammer that point, it really is a nice code base. I've worked on a lot of both open source and proprietary code bases written in sort of a combination of Python two and Python three, or you know, now Python three, but we're migrated from Python two, with very bespoke setups and environments that are clearly developed from an engineer's desk somewhere inside of an office. And warehouse, fortunately, is not one of those code bases.
Tobias Macey
0:45:08
And is it worth digging more into the actual funding behind this work, and how that structured and just some of the overall sustainability efforts to be able to maintain and upgrade the Pi Pi and warehouse platform?
Nicole Harris
0:45:22
Yeah, so I can I can talk about that. As I mentioned earlier, I'm a member of the Python packaging Working Group, which raises money for for not just pi pi for any packaging related project. And it was through that, that, that we got this this grant from the open technology fund or TF to actually be able to do that work. It's the second major grant that we've got for pi pi, you might be familiar with the fact that we got a moss were granted a moss grant Missoula open source. Grant last you must last year, and that was to migrate from the old version of API to this to the new warehouse Kobe's into retire that old code base. So so far, through the packaging Working Group, we've had two fairly substantial grants, which have allowed us to really improve the packaging index, that working group continues to, to work to, to make grounds for for different subjects, not just pi pi, but also many of the tools that interact with pi pi, such as Pip. So we're hoping that in the next sort of year, we will have more more money coming in from those from those from those applications that we make them be able to fund more sustainable development for Python, the packaging ecosystem in general. The other thing to mention is that we have very fortunate with pi pi, to have a number of great sponsors who actually give us the infrastructure for free, I don't have the data right now, in terms of how much that's worth, but it's certainly millions per year that it costs to actually run the Python packaging package index. And a lot of that is is borne by how CDN fastly if you donation to us is actually quite enormous. So in terms of sustainability, we we have a mixture of these, the funding coming through from grant applications, and we have you know, the these different companies giving us their their services to enable us to keep the service up. The other thing that we we we appreciate is we have a donation page on polka.org, where members of the community can donate towards the Python packaging Working Group, so that we can then have a budget to be able to pay for maintenance, and improvements to both pi pi and other projects. An ideal scenario in the future is that we would have enough kind of recurring donations from the community that we would be able to set up a more reliable either part time or full time situation where we have people working on packaging as their job. Because at the moment, we really have mostly just contracts that come and go depending on the money that comes in.
Tobias Macey
0:48:18
Are there any other aspects of your current efforts on the Pi Pi infrastructure, or any other aspects of the overall platform that we didn't discuss yet that you'd like to cover before we close out the show?
Nicole Harris
0:48:30
Yeah, I can't think of anything. Can you think of anything real?
William Woodruff
0:48:33
Oh, no, no, not in particular. I mean, there's there's sort of interesting things about webauthn and to TP that they go into, but they'll be a bit in the weeds.
Tobias Macey
0:48:42
Well, for anybody who does want to dig deeper into that, if you have any specific references that you found useful, I can add them to the show notes. And for anyone who wants to follow up with either of you or get in touch and follow along with the work that you're doing, I'll have you each have your preferred contact information to the show notes. And so with that, I'll move into the and this week, I'm going to choose the show the expanse, I started watching that recently, and I've gotten through the first season and into the second. And it's just very interesting and well done sci fi series chronicling some dramatic events that far into the future where humans have gone beyond Earth and started populating other areas of the solar system. So it's a interesting and well put together show with a lot of good sort of environmental aspects such as the Creole language that people speak further out into the asteroid belt. So if you're looking for something new to watch, I recommend that And so with that, I'll pass it to you. Do you have any pics this week?
William Woodruff
0:49:37
Sure. Yeah. I don't know if I have a media pick. I've been reading. I'm not actually normally a big nonfiction person. But I've been reading an autobiography of Abraham Lincoln by Carl Sandburg, who's some a well known American poet. So a little bit out of his like, I think, not, not his expertise, but out of his field of renown. But it's been a pretty interesting, a pretty interesting read so far. It's actually a surprisingly nuanced biography of his life in the sense that it goes through sort of the both political and military failures that he encountered. And it's just been, it's been a sort of interesting to read, because, you know, you learn this stuff in like 10th grade in American high schools, but then you just then it gets dropped.
Nicole Harris
0:50:14
I do have an answer.
0:50:17
So, last week, or the week before, I watched a documentary on Netflix called the Great hack, which was particularly interesting to me, because I live in the UK. And it talked about Brexit and Cambridge Analytica and and what's sort of been happening, I haven't followed that probably as closely as I should have. So yeah, anybody out there who's kind of interested in documentaries, it's certainly very, very interesting and very topical at the moment with regards to the current political climate.
Tobias Macey
0:50:50
Well, thank you both very much for taking the time today to join me and discuss your work on the API platform and infrastructure and some of the ways that that will improve the overall viability of it in the long term and improve the available workflows for people using it. So I appreciate all of your efforts on that front and I hope you enjoy the rest of your day. Thank you.
Nicole Harris
0:51:11
Thank you.