almost done

nietaki's notes on software and stuff

Trust issues: trouble in package paradise

Code BEAM STO 2019 talk

Earlier this year I gave a talk at Code BEAM STO about a proposed solution to the ever more real risk of hidden malicious code in our library dependencies. You can watch the whole thing here:

UPDATE: I have since dropped active development of the Hoplon project, but I hope something like it will become reality when the tech community is ready for it :)

String​.to_existing_atom​/1 a double-edged sword

I’d argue Elixir has relatively few gotchas. It’s a simple and consistent language and when you first learn it there’s only a few things that are genuinely counter-intuitive and catch you by surprise.

One of the examples could be the difference between binaries and charlists and why iex sometimes seems to do weird things to your lists:

iex> l = [19, 7, 16, 119, 97, 116]
[19, 7, 16, 119, 97, 116]
iex> Enum.drop(l, 1)
[7, 16, 119, 97, 116]
iex> Enum.drop(l, 2)
[16, 119, 97, 116]
iex> Enum.drop(l, 3)

One of the other ones comes when you start working with atoms and get a little too trigger-happy with them. What you could hear from your more experienced teammates is something like this:

You shouldn’t really use String.to_atom/1 on user-supplied data. The BEAM has a limit on how many different atoms you can have and they’re not garbage collected!

With data coming from outside the system, stick to strings or use String.to_existing_atom/1 instead!

This is good advice and the official docs agree. It seems like an easy choice too - if you take the approach that all atoms you expect to see in the system are known at compile time and you won’t be creating any new ones during runtime, there’s no reason not to do it! You get all the safety and no problems!

From my personal experience it’s true the vast majority of time. But there are situations where it could blow up when you least expect it (or just in production). Pull up a chair, let me tell you a story

read more

I'm stealing API keys from your site

Hoplon - protecting yourself from malicious packages

Earlier this year I presented my latest project - Hoplon - at the London Elixir meetup. I’m thinking of putting some more work into it over Christmas, so I figured I might gather the materials about it in one place:

Hoplon is an Elixir developer tool that helps you validate your dependencies contain no hidden malicious code. Motivated by horror stories from the JavaScript community such as this hypothetical one and this very real one.

You can see the details and a live demo in the recorded talk.

Here’s the slides, with all their happy colourful diagrams:

Hoplon as it is right now is pretty much a proof of concept, but I’m thinking of making it a bit more production ready and adding some advanced herd-immunity type features. Keep your fingers crossed!