Non-technical security best-practices for open source projects | Hacker News Reader

Non-technical security best-practices for open source projects

git.sr.ht

143 pointszdw27 comments

Obviously work in progress, but one important thing is missing here, IMO:

"Make the right user behavior is the easiest for them."

If you want users do something, make it the easiest course of action for them and so that they have to go out of their way to do something else (that you don't want them to be doing).

If there exists a convenient shortcut the users will be using it even if it has adverse security implications.

For example, if you want them to be using SSL when connecting to your product, make that your client uses SSL by default and you need to specify additional option to do something else.

In Linux kernel world, in the old times it took effort to be constantly updating the kernel. Now it is the opposite -- it does not take effort to keep it up to date and actually requires action to stay at a particular version.

Now I understand to a large extent this is thanks to work done by distros, but this would not be possible without stability of APIs and drivers.

This advice is far too often used by bad actors to push user hostile behavior.

Doesn't make it any less effective for the good guys.

Some software include so much freedom that it actually hurts users. Now the idea isn't to take away any freedom but rather somehow steer users into using the software correctly.

I like to think about this advice in terms of "expert mode"--if you are regular user I am steering you into safe behavior that you probably expected, but if you are an expert I give you the freedom to do whatever you want to do.

My summary

1. Make bug reporting easy with an obvious place to report

2. Do not change interfaces between versions because users will hesitate to upgrade to get security patches.

3. For libraries, maintain security fixes for older versions, provide clear documentation so that users can upgrade to newer versions.

4. For applications, either change slowly or make a compelling case for change.

And there are those two links, that are very good:

https://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html

https://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html

"Rusty's Rules for APIs" for those wondering.

(Referenced on p. 40 of Greg K-H's preso.)

I feel so many companies, especially of operating systems and web browsers, need to understand point 2.

2 has been a huge point of pain for me especially since everyone seems to be afraid to increment their major versions now since they don't want to lose the flexibility to break their API.

So does number 2 mean you can't ever change your interface?

I think #2 is imprecise in its wording. Break between major versions (though, really, you should only break it for a good reason).

What I am seeing is breaking changes more and more in minor and patch versions, especially since developers are afraid to cut a 1.x so they hide behind the 0.x semantic versioning unstable interface clause.

This would also only seem to matter if you release security patches to older major versions... otherwise those same people still wouldn't get security updates.

I would say, be aware that major inforface changes mean that you might need to support the previous version with security fixes for a long time or leave non-adopters exposed.

Yeah, that was really where my question was trying to get to... what unspoken assumption is being omitted?

Use minors to add but beware of bloat. And majors to purge.

Breathe in, breathe out. Like the tides.

The actual slides (as PDF): https://git.sr.ht/~gregkh/presentation-non-tech-security/blo...

@dang:

Since GitHub submissions were altered to show more of the URL (enough to show user/team/organization name), could the same be done with other repository hosts like sr.ht?

Most of these times, these request are unseen or forgotten. It's better to send it in an email to hn@ycombinator.com

I wonder if the right approach here is for HN to just use the public suffix list [0], and then sites like SourceHut should be added to it.

[0] https://publicsuffix.org/

Looking at that, it would work (to the extent the list is complete) for things like GitHub pages (at github.io, like foo.github.io) but it doesn't work for GitHub user pages and repositories like github.com/foo or github.com/foo/bar. If the URL included a ~ like old school user sites then it could be automatically detectable (assuming others don't randomly throw a ~ in to their paths) like our university websites back in the day with foo.edu/~bar or math.foo.edu/~bar. Of course, now you've got sites using @ (Replit) instead of ~ to indicate a similar notion (that it's a user page and not, properly, the work of the main server hosts/owners), and GitHub and others don't include any kind of sigil providing this kind of information.

Email the HN mods directly at hn@ycombinator.com

The mobile UI for sr.ht is pretty impenetrable. Navigation links look exactly like unclickable text...

you mean the summary, tree, log, refs on the navigation bar? I kinda agree, but it's not totally "impenetrable" though

other than that, all links are in blue color to me

I mean, it takes me more than the 2 seconds I’m willing to expend to understand how the UI works.

In theory it should take zero.

Link to the talk: https://www.youtube.com/watch?v=gKwqhFTrbM8

my fav quote:

> evolve systems over time so no one notices. (22'5")

> __attribute__((deprecated)) is evil

I was wondering if anyone had some insight on this?

I understand that deprecating a function usually means you'll be removing it at some point, which goes against the rule "Evolution is addition only", but is it that bad to try to steer users towards a better API, or am I missing something particularly bad about that deprecation attribute?

“Users will not update take your security fix if they are afraid you will break their current system.”

Please, somebody notify Microsoft's Windows dev team. They desperately need, but did not get the memo.

Reply on news.ycombinator.com