Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LibreSSL

libressl.org

Post reply on HN
Print view View original

231–240 of 262 posts

Re: LibreSSL

#231

Post by KMag »

rpdillon wrote: post #217
gnoway wrote: post #161

Earlier quoted context omitted.

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…

> Git uses SHA-1 hashes, which have not been considered cryptographically secure since 2005. That a vast oversimplification. There are still no publicly-known preimage or second-preimage attacks against SHA-1. Even the collision attack in 2005 was limited insofar that it reduced the search from a brute-force 2^80 to 2^69. Perhaps you're referring to a length extension attack, but I admit I don't know much about those…

In terms of C source files, unless the fist C source file being extended is at least 64 petabytes long, a length extension attack is going to embed null bytes in the C source file. I don't know chapter and verse of any of the C standards or GCC/Clang extensions, but I wouldn't be surprised if even string literals and comments including nulls cause problems for both GCC and Clang.

Anyone care to chime in/experiment with ways to embed nulls in C files such that either GCC or Clang will continue compiling code after hitting a null byte in the middle of a file? (I'm not talking about an escaped null in a character or string literal, but actually a 00 showing up in hexdump -C of the source.)

EDIT: I think it's safe to assume people will notice someone trying to sneak a 64-petabyte C source file into the codebase. With apologies to Sweet Brown, aint nobody got time for [downloading] that.

Re: LibreSSL

#232

Post by clarry »

afiler wrote: post #228
q3k wrote: post #221

Earlier quoted context omitted.

As far as I read up about this some time ago, it boils down to the following reasons: - CVS is simple - it's small (fits on a floppy with bsd.rd) and easy to use on exotic/slow architectures - CVS is preferable for their current contribution workflow (centralized) - CVS is treated as a tool that, currently, just works (tm)

It seems ever-so-slightly ironic that support for exotic architectures is considered a plus in this case, while support for exotic architectures is being ripped out of the OpenSSL/LibreSSL codebase. (Though probably not deeply ironic, since CVS is comparatively simple.)

It might seem ironic to people who do not understand the difference. OpenSSL includes wrappers and (probably untested since N years ago and therefore broken) code branches to work around bugs in old broken exotic systems that do not get fixed. This sort of code is a maintenance burden if you try to keep it working and just useless if you don't. It is also likely to introduce bugs. Getting rid of it simplifies the code and gets rid of bugs along with it.

OpenBSD's system level support for exotic platforms has more to do with drivers, compiler & tool chain support, boot code, etcetra. These do not create a jungle of ifdefs and workarounds in userspace applications. And if these platforms are broken, they are fixed instead of worked around with more jungle and weed. So support for these things does not add bugs for others.

On the contrary -- getting your software to run on a SPARC64 is more likely to expose flaws in your code.

Re: LibreSSL

#233

Post by pimlottc »

rakoo wrote: post #95
DiabloD3 wrote: post #5

Comic Sans? Really? Edit: To those downvoting, yes, I saw the footer. This doesn't excuse their childish behavior. I will not be donating to this project if this is the level of seriousness they have for it.

You know, what you really care about is them spending time on writing good software, not writing good websites. They don't have time for this, they don't have money for this, and they don't want to spend human CPU on this. Oh, and while we're at it, the OpenSSL page [0] isn't much better visually speaking. Would you donate to them to make OpenSSL better ? [0] https://www.openssl.org/

It's one thing to focus on the code over the website and another to deliberately thumb your nose at people with an ugly font.

It's not all just window dressing; a pleasant, professional website will help to attract more attention and resources.

Re: LibreSSL

#234

Post by copergi »

rodgerd wrote: post #57
antirez wrote: 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.

OpenSSH also deliberately trashed cross-platform compatability. This makes it amusing whenever someone flounces off to OpenBSD because they think systemd should have been written portably.

Yeah, fuck those openbsd guys and their totally not portable openssh that you can't run on anything but openbsd!

Re: LibreSSL

#235

Post by copergi »

papaf wrote: post #190
copergi wrote: post #164

Earlier quoted context omitted.

>Portable OpenNTPD seems to have died: https://wiki.archlinux.org/index.php/OpenNTPD If you follow that through the series of links, you find that it is just an assumption based on one guy who didn't know the project existed thinking unchanged = unmaintained.

Are you sure? There hasn't been a release for 8 years. I followed the links a while ago after hitting an intialization failure bug that leaves Linux boxes with the incorrect date. I found that neither Arch Linux or Redhat consider OpenNTPD to be supported on Linux. Edit: a better link https://bugzilla.redhat.com/show_bug.cgi?id=430143

11/11/2009 is not 8 years ago. That "better link" is exactly what I was referring to.

Re: LibreSSL

#236

Post by clarry »

deegles wrote: post #222
sigzero wrote: post #180

Earlier quoted context omitted.

I don't agree at all. I am betting that once LibreSSL is "done" it will get adopted heavily and the community will have a cleaner and more secure code base to work from going forward.

I trust the OpenBSD team to get it right.

I'm going to quote somebody out of context. Please bear with me...

  What I am seeing is that we have a ridiculously upside-down trust
  model -- "Trust the developers".

  We never asked for people to trust us.  We might have "earned some" in
  some people's eyes, but if so it has always been false, even before
  this.  People should trust what they test, but the world has become
  incredibly lazy.

  We build this stuff by trusting each other as friends, and that is
  done on an international level.  If anything, the layers and volume of
  trust involved in software development should decrease trust. Oh
  right, let's hear some of that "many eyes" crap again.  [..]  All the
  many eyes are apparently attached to a lot of hands that type lots of
  words about many eyes, and never actually audit code. 

  If anything, the collaborative model we use should _decrease_ trust,
  [..]
Before anyone gets the wrong idea, I'm not trying to attack any individual here. But so many software vulnerabilities, goto fail included, Heartbleed included, have caused such angry response from people. That the bug was trivial. It should've been caught by static analysis, smart compilers, correct review process, careful third party readers, TDD, UFOs, ADHD, . It is easy to say all that in hindsight, because you are for most part right. So why weren't these techniques used?

You can't blame the developers for everything, they have work on their hands and you are not entitled to anything more from them. You also can't trust developers. If there's sloppy code, someone has to notice it and point it out. Someone has to fix it. If there are sloppy development practices and it is evident that the upstream developers do not care, someone has to notice that and let the world know. Then maybe create a fork and try to do better.

So anyone capable of reviewing code and diffs: please try to do it if you haven't before. Try to do more if you're already doing it. And remeber, you do not have to be an expert programmer to notice a duplicated goto fail line.

Or if you can write tests, why don't you contribute?

[quote] http://marc.info/?l=openbsd-tech&m=129261032213320&w=2

Re: LibreSSL

#237

Post by a8000 »

gpcz wrote: post #183

I've been thinking recently about Heartbleed, and I was wondering if by writing C code to implement various network and cryptographic protocols, we're acting as human compilers for something that might be better represented in a more abstract format. I know there's some research on this already (the Austin Protocol Compiler), but does anyone here know of any other serious efforts to take the human out of the equation…

There are efforts by Microsoft Research in this direction: http://research.microsoft.com/en-us/projects/slam/ They have developed several domain specific languages and specification tools for developing drivers. I think similar methods are applicable to protocols.

Re: LibreSSL

#238

Post by a8000 »

pimlottc wrote: post #233
rakoo wrote: post #95

Earlier quoted context omitted.

You know, what you really care about is them spending time on writing good software, not writing good websites. They don't have time for this, they don't have money for this, and they don't want to spend human CPU on this. Oh, and while we're at it, the OpenSSL page [0] isn't much better visually speaking. Would you donate to them to make OpenSSL better ? [0] https://www.openssl.org/

It's one thing to focus on the code over the website and another to deliberately thumb your nose at people with an ugly font. It's not all just window dressing; a pleasant, professional website will help to attract more attention and resources.

People not using Windows, wont see this font to begin with, unless they chose to install Comic Sans for some reason.

Re: LibreSSL

#239

Post by papaf »

copergi wrote: post #235
papaf wrote: post #190

Earlier quoted context omitted.

Are you sure? There hasn't been a release for 8 years. I followed the links a while ago after hitting an intialization failure bug that leaves Linux boxes with the incorrect date. I found that neither Arch Linux or Redhat consider OpenNTPD to be supported on Linux. Edit: a better link https://bugzilla.redhat.com/show_bug.cgi?id=430143

11/11/2009 is not 8 years ago. That "better link" is exactly what I was referring to.

From the OpenNTPD homepage at http://www.openntpd.org/

    Portable OpenNTPD 3.9p1 released May 14, 2006.
It would be good if you could explain what I am missing. If there are more recent Linux releases and the information on the Redhat bug tracker is incorrect I would like to know. I'd rather be running OpenNTPD than ntpd.

Re: LibreSSL

#240

Post by boklm »

mrweasel wrote: post #94
boklm wrote: post #88

Earlier quoted context omitted.

Because people might be interested to review their changes, and CVS makes that very difficult.

How so? CVS do make branching and merging rather annoying, but I don't see how reviewing changes becomes difficult. It's a lot easier to track the changes to the entire OpenBSD source three, compared to the Linux kernel. Git and Mercurial are extremely nice tools, but the flow of patches and branches quickly become rather hard to follow. CVS doesn't have most of the features that newer tools have, so there's stuff yo…

There's many problems that makes it very annoying to review their changes:

- CVS commits are per file. You can't see changes made by a single commit to multiple files.

- CVS cannot rename files. You have to create a new file and remove the old one. So you cannot follow history of the changes.

- CVS is really slow. You cannot clone the repository locally, so it takes a few seconds to show any change, whereas git shows you any commit and logs instantly. And you can't do it offline (for instance if you need to spend a few hours in a train).

- git log / show / diff is so much better than cvs log / diff.

- you can't use things like git blame

- they've lost all openssl.org history. If they were using git, they could have cloned the openssl git repository, and add their commits on top, keeping all history (which is often very useful when you're trying to understand why something has been done like this, or who introduced some change).

I'm not an openssl expert, so I didn't plan to review their changes anyway. But if I had to, using CVS would be the most annoying thing.

Post reply on HN