Here is the translated Russian version of this interview.

The company of speakers at Moscow Python Conf++ 2020 is great, and it's not a good luck but thorough Program Committee's work. But who cares about achievements, it's much more interesting what the speaker thinks about our own questions. Conferences suits good to find it out, get insider information or advice from an experienced developer. But I got an advantage of being in Program Committee so I already asked our speaker Kushal Das some questions.

A unique feature of Kushal's speeches is that he often unveils «secret» ways to break Python code and then shows how to write code so that the NSA can't hack it. At our conference Kushal will tell you how to safely develop and deploy Python code. Of course I asked him about security.



— Kushal, please, can you introduce yourself, your work, what are you doing with Python and all these things?

KUSHAL DAS: I live in India, I'm currently working as a public interest technologist at a US non-profit organization, the Freedom of the Press Foundation, where I help to maintain SecureDrop project. SecureDrop is an open source whistleblower platform. And it is mostly written in Python. Other than this project I am also involved in various upstream open source projects including the Python programming language itself. I'm one of the CPython core developers and I'm also a director of the Python Software Foundation board.

I am writing Python from the end of 2005 and almost my whole career is built on top of this particular language, and also Linux. These are two major things, where I worked on. I'm also a part of the Tor Project core team. As many people already know, Tor is a project, which helps to keep your privacy online.

— Yes, Tor is amazing. Software developers all over the world use it for access to API and documentation, for example, which are blocked due to some local laws. Your talk will revolve around security, so I have few questions.

First of all, there is a popular opinion that security itself is too hard for an average developer without special training. According to that we as an industry should provide tools and ecosystems, so that the software we create was somehow secure by default.

What do you think, should we teach people or provide completely safe tools to handle security for them?

KUSHAL DAS: I'm actually in a middle of this, because, as you say, security is hard. But at the same time with some basic trainings to new programmers, when they start learning programming, or start working in the company, we can train them for most of the issues that we see.

Sometimes, we see that actual security errors happen in production. Among those are breakings, data leakage or data theft. Mostly, all of those issues are related either to a misconfiguration, or to lack of upgrades, or to people writing a poor or even insane code.

I believe that most of the basic errors that we see can be taken care of, if we try to train new people or even the people who work in the industry for a long time. But at the same time, with newer tools, newer automation, newer processes we can also fix things that can be difficult for a human eye to identify.

A very simple example would be dependency checks that now GitHub has. If you have bugs in a Python application, and if you are using some old version of an independent module which has some sort of CVE security flow, GitHub has a way to tell you as a developer — «Hey! You should upgrade this!» — and the bot automatically tries to submit PRs also, so that we can upgrade.

So, it should be something like a good mix and match between training and tools, but if you ask me personally, I'd still prefer as much training as possible, because it's people, who are typing on the computer, and most of the mistakes are still human mistakes. We can not solve all human errors by technology.

— Yes, unfortunately so. Modern software development relies heavily right now on the public repositories like Python Package Index, node.js, npm and so on. With modern development it's always like pip install or poetry add. From your educated opinion, how high are security risks for an average developer who works on some Python backend in medium sized company to just pip or poetry addsomething to the project? Are risks acceptable or do developers need to really think about something like some trivial vulnerabilities that they can succumb into?

KUSHAL DAS: That's actually a great question, because all the different projects repositories we maintain, where people can download this modules for different languages, all of us are actually trying at the same time on how to make it more useful and easy, so that the developers don't get into a trouble.

So, for Python we can see that we have a Python security mailing list, where people actually find out if there are any issues with their newest uploaded Python modules. Previously we saw cases where people tried to use something known as typosquatting. That is, where a package name had been almost similar to a very well-known package, and developers used the wrong packages without knowing. From the Python's point of view, a lot of those things we are taking care of are in PyPI.

In addition, when you are installing any package using pip you can actually verify it. So that you at least know this is the right package which you downloaded, and also to verify that the download is perfect and more secure. There is a PEP 458 which talks about secure PyPI downloads with package signing.

These works are still going on. And for average developers, I would say, before starting with any new unsigned module, if they just look at who is the author, how many people, try to find out where it is hosted, a source code, and how many people are complaining about any issues or bugs, or if any other big projects are using it.

That 15-30 minutes of search will give them a lot of extra benefits. If no one else in the world other than the author is using that package, it may not be the right way to use that. And if they can see that there are option packages or software using it, there is a much better chance that you'll be in safer coding condition because there are so many people who are looking into that particular package.

— Modern development requires us to think before using any packages and dependencies. It can be due to security, due to maintainability, popularity and lots of other things.

Talking about public packages and dependency repositories, recently with node.js ecosystem and the npm, I saw built-in security monitoring with background checks like if I do npm install something.

The NPM itself provides me with background security check results like «among the packages you just installed there are two high security risks, ten medium risk and you can do these commands to patch or update them or roll back». It's like built-in tools. What do you think about such solutions and can we expect something like this for the PyPI?

KUSHAL DAS: First of all, I have never used NPM in my life, except maybe once or twice to test on something, so I can not directly comment how great it is that way. But just from the sound of it, it keeps a visual idea to the developer as to a person. And a lot of these things are also part of the whole UX story.

That is if we, developers, are talking to average designers, as to UX persons. We should try to figure out on how to better represent the data so that the third person, the final developer, who's going to install those tools or modules, is actually going to look at it.

Because if there is too much information, we all have a tendency to follow the «click-click-click» or «I agree-button» kind of scenario. So, that has to bring us somewhere, and as far as the Python and the pip development are concerned I can not comment because I don't know what is the future plan for all of it. I guess, I hope rather, that someone already filed an issue asking for this similar feature. And that pip authors can plan ahead for the future, when they want to add this similar kind of things.

Right now the maintainer team is also a little bit larger than what we had previously. I think there are seven people with commit access.

— I hope that as years come people will think more about security and add more implicit checks into our ecosystem. Let's talk a little bit about your upcoming conference talk. As I can see it is built around security checking dependencies and packaging that called a safe way.

We will not give a spoiler to your talk with this interview, but from a security expert point of view, your point of view, what else should we, developers, consider while checking our application security. For now, we will secure our dependencies and we will secure our packaging.

What else should average developers check for? What should they look for?

KUSHAL DAS: I think one of the first points should be having everything updated. I mean make sure that you at least got through that list and things you are depending on — including operating system level, doesn't matter it's running a Linux, Mac, Windows or even iOS — are updated or you at least went through appropriate package modeling to understand what other things can go wrong.

From a programmers' point of view, the new programmers' problem in most cases, even though I had the same tendency, is to trust the user input. You have to less trust that typing is really sane and will not cause any other trouble, and do everything to make sure that input is what it should be — that's one part.

The other part is that whenever we are opening something, we should make sure that we are closing it. It can be realized as a physical door, like when you are getting into the office or in a secure location you have to make sure that your door is closed after you entered — and in the same way in programming, when we are opening files, sockets, or any other things, or access to something else, we should make sure that after the work it stands properly clear and closed.

From the programming point of view, I think, those are the two very basic things which many people forget.

— From your personal experience, given an average backend Python developer of a medium skill level, what is the top one security related error? Is it user input? Is it dependencies? Is it packaging the application secure way? What have you seen most often?

KUSHAL DAS: The issues I saw were mostly related to an incorrect input.

In 2011, I was developing a tool for the Fedora Project. I forgot to clear up all the temporary files I was making. In that particular case these were dumps, and it caused a major force for infrastructure to go down — thanks to my not a nice code, in one way.

But that was again the same idea of cleaning up, making sure that the code is cleaning up the things I'm creating or opening. So, that was one big lesson for me. It was something like — «Hey, I just created it and it works on my laptop.» Yet, doesn't mean it will work in the actual production.

Just think about those two parts: whatever runs on your laptop doesn't mean that it will run on someone else's computer properly in the same way. We always think that the environment may be the same, and it will never be the same. Even bigger companies have trouble figuring out what is an actual environment on the client side.

Just keeping that in mind will help a lot. Please comment more on your code along with the documentation. This is a request not only to all new developers, but even to senior ones. You know, if you don't look into a code for a few months or few years, it becomes very difficult to get back and understand why you wrote something that time.

Road signs are really great to battle with complexity.

In just two weeks, we will see Kushal at Moscow Python Conf++. Join us to discuss developing secure Python code and possible ways to automate this process.