Live data from Hacker News

LibreSSL

libressl.org

191–200 of 262 posts

Re: LibreSSL

#191
post #101
post #83

Earlier quoted context omitted.

Ah yes, the kind of professionalism I've come to expect from OpenBSD. They make decent software, but boy could they use some work in the PR department.

I'd rather have great software and shitty PR than the recent trend of obnoxiously beautiful landing pages for “world-changing” shitty web apps.

With a PhD in architecture, design and branding, there's something about the extreme simplicity of OpenBSD's web pages that I find really attractive. "Perfection is achieved, not when there's nothing left to add, but when there's nothing left to take away".

Re: LibreSSL

#192
post #67

Earlier quoted context omitted.

While it is funny, I think using Comic Sans is actually more hipstery than ranting against it, which is too mainstream today (the same goes for blink tags).

There is a pro-type / mordern-type version of comic sans http://comicneue.com/ :)

I added it to homebrew-cask :)

https://github.com/caskroom/homebrew-fonts

    brew tap caskroom/fonts
    brew cask install font-comic-neue

Re: LibreSSL

#193

Earlier quoted context omitted.

The reasoning there is, certainly post-Heartbleed, very scary. Their conclusion boils down to that they want to use the system-provided OpenSSL on Android, rather than shipping NSS. This might be fine if you're running a Nexus device that still gets updates to the latest Android (Nexus 4 and later?). But for everyone else, that's effectively forcing people to get a new Android phone if they don't want to get stuck wi…

I mean couldn't you say the same thing if a vulnerability was found in NSS?

No, because Android system updates are slow to come (or may never happen), while anything coming from the Google Play store (like Chrome) is timely.

Re: LibreSSL

#194

https://twitter.com/matthew_d_green/status/45696043584599654...

Did you get to the part where Prof. Green says:

@MiodVallat @cwlcks Well then I withdraw my earlier comments. What happens in BSD when the system RNG lacks entropy? Does it block?

Re: LibreSSL

#195

One annoying thing about OpenSSL is its license. I hope The Better Replacement™ fixes that as well (especially if its name gets to contain the string "Libre"), and it is not going to happen by forking OpenSSL.

They are already placing completely rewritten files under ‘better’ licenses, so the license switch might happen file-by-file over a long period of time.

Is that strategy possible at all? Are there cases tested in courts (both US and EU) that assert that the file-by-file licence replacement really works?

Re: LibreSSL

#196
post #31

I imagine supporting non-POSIX operating systems, or not exactly conforming ones, to have its challenges, but is it really hard to make this stuff working in Linux and Open/NET/Free BSD from day one? It seems to me a better approach to start this way, without to mention that the potential developers base you get if you support Linux ASAP can be larger.

I'm sure that portability is a major goal, but "from day one" isn't. Better to focus on correct, high quality, readable code first and then deal with a portable version. And OpenBSD C code tends more toward generic UNIX than some others, so shimming is less painful than it could be.

There really are a lot of parallels with OpenSSH's history. There were the "Oh, God! Theo forked SSH!", "It's just OpenBSD, who uses that?", and all the rest. Now everyone uses it, and it's a good thing. The wait time for it to be ready and available to all platforms was a small price to pay, well worth it, and quite small in retrospect.

Re: LibreSSL

#197
post #41
post #36

Earlier quoted context omitted.

Probably none. Windows has its own CSP library which is a little more convenient in a win32 context than OpenSSL or anything POSIX TBH. I think they're doing the right thing here.

There's a ton of Windows software that uses OpenSSL as their security library. Moreover, there is a lot of Windows projects that are written in inherently portable way and using OpenSSL API is the most natural choice for them. If StartSSL manages to topple OpenSSL and to discourage any further OpenSSL development, then that'd be a very bad thing for a lot developers.

> There's a ton of Windows software that uses OpenSSL

And those projects can upgrade to the heartbleed-patched version of OpenSSL and keep going. If LibreSSL eventually makes it to Windows, they can switch.

OpenBSD can't do everything at once.

Re: LibreSSL

#199
post #161

I may have a stupid question but... While I really enjoy Theo's talks and writings, I wonder if the fact that the VCS is CVS ain't a security issue in itself? It's been really a long time I haven't used CVS but I remember that attempt to introduce backdoors in projects using Git as a (D)VCS have been caught (it was in the Linux kernel I think). IIRC some attempts were caught precisely because it's hard to fake SHA ha…

Git uses SHA-1 hashes, which have not been considered cryptographically secure since 2005. Git and CVS are both just tools. They each provide a server implementation, but it's uncommon to use either of these for write access in large projects. It's more common to wrap CVS or Git with a different frontend like HTTPS or SSH. My guess is that the OpenBSD guys use OpenSSH. This team is fanatical about security and proces…

The edit button is gone. I guess these expire?

My reply was not intended as an attack on Git. I use it daily and would choose it 10 times out of 10 vs. CVS for a new project. I just think the assertion that Git 'saved' Linux from some backdooring attempts because it's decentralized and uses cryptographic hashes is wrong; it's not the tools that make this happen, it's the processes around the use of these tools which do that.

I don't know any OpenBSD developers nor do I have any inside knowledge of how their team works, but I know from observation that they are a small team with high standards for code style and quality. They don't just let anyone commit code and appear to be thorough with code review. When procedural/practice problems are identified in the industry, they are proactive about mitigating or fixing those. They have a demonstrated track record of good releases. Basically, I don't see any reason to question their use of CVS.

Re: LibreSSL

#200

One annoying thing about OpenSSL is its license. I hope The Better Replacement™ fixes that as well (especially if its name gets to contain the string "Libre"), and it is not going to happen by forking OpenSSL.

How about projects that currently have an 'OpenSSL exception' in their license. Will they need a LibreSSL exception in their license too now?
Post reply on HN