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

201–210 of 262 posts

Re: LibreSSL

#201

Post by clarry »

rurounijones wrote: post #9

Since this is related. I have a question: How can they know that they have not broken something in their flensing without any automated testing since no tests is one of the big problems with OpenSSL?

Believe it or not, there are other ways to spot problems besides automated testing, which wouldn't catch every problem anyway (that's why we need human audits like the one OpenBSD is doing).

Yes, software existed before TDD and ADHD.

That's not to say tests don't help. If you are interested, why don't you contribute?

Re: LibreSSL

#202

Post by adamman »

antocv wrote: post #130

"No we dont need help with making web pages" its just a bunch of html very simple 1990s tags and it still looks and works much better than any html5 css3 bootstrap fanboy page Ive ever seen. Awesomeness

You must be trolling.

The site is ugly and I'm sure they would agree. That clearly is not the focus of their work.

Re: LibreSSL

#203

Post by acqq »

ZoFreX wrote: post #133
abcd_f wrote: post #34

> removed MacOS, Netware, OS/2, VMS and Windows build machinery What are the plans for native Windows support? I don't know what they mean by "The right Portability team in place", but it'd be a joke if the lib would require CygWin or some other external portability scaffolding. And without proper Windows support LibreSSL will simply fragment OpenSSL user base. I guess it's still better than nothing, but it definitel…

I don't see why this product would have a different porting strategy to the usual way OpenBSD projects (such as OpenSSH) handle it - target OpenBSD exclusively in the core project, and support other platforms with ports. Presumably that's what they are going to do here.

As far as I know OpenSSH doesn't work natively on Windows, only over Cygwin, that is, with the whole Linux environment by Red Hat.

Re: LibreSSL

#204

Post by hsivonen »

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…

Rust (http://www.rust-lang.org/) is a serious effort to build a language that's close to metal like C but safe.

Re: LibreSSL

#205

Post by TacticalCoder »

gnoway wrote: post #199
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…

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…

(first note that I didn't assert anything: I asked question(s) and used "IIRC" etc.)

I found the story back and things are, IMHO, actually quite interesting... If only because the attempt was made after someone ill-intentioned gained access to Linux's CVS repository.

Back then Linux was still using BitKeeper (decentralized) for Linus hadn't created Git yet (so I was not remembering things correctly here). But apparently some people didn't like BitKeeper so there was a CVS clone of the BitKeeper version. And it's in the CVS repo that the attempt took place (after someone hacked his way into the server hosting the CVS repo).

Here's the story:

https://freedom-to-tinker.com/blog/felten/the-linux-backdoor...

Now even though Linus didn't choose SHA-1 for its cryptographic properties and even if SHA-1 is not SHA-256 nor SHA-3, it still looks like an attacker gaining access to a CVS repo would have a much easier time inserting a backdoor than an attacker gaining access to DVCS using cryptographic hashes (which user KMag here explained nicely).

Re: LibreSSL

#206

Post by X-Istence »

slashdotaccount wrote: post #184

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

Now go read this: https://twitter.com/MiodVallat/status/457169266748715008

And the whole thread ... and problem doesn't exist.

---

Same thing was brought up in this HN thread: https://news.ycombinator.com/item?id=7604364

Re: LibreSSL

#207

Post by wolf550e »

XorNot wrote: post #189
KMag wrote: post #176

Earlier quoted context omitted.

SHA-1 has been shown to not be collision-resistant. Correct me if you've heard otherwise, but I believe SHA-1 is still believed to be second-preimage resistant. In other words, with fewer than 2 * * 80 trials, an attacker can generate two files that have the same SHA-1 hash. (In the case of C source files, this probably means embedding a nonsense comment in the middle of each file, probably several hundred to several…

Conversely there are other signing techniques. GPG signed tags is an officially supported method. Probably more importantly though, Git encourages everyone to have the full repository lying around. Even if you inserted a vulnerability in a master, there would still be thousands of copies of code which could be independently compared to find the exact changes which were made.

I think gpg signs just the sha1 the tag points to (root of merkle tree). Also, when comparing local repo against remote repo during fetch, I think git assumes that as long as the sha1 of a commit did not change, there is no need to compare further. So the substitution will not get propagated to people who do "git pull" but people who do "git clone" will get it.

Re: LibreSSL

#209

Post by rgbrenner »

mercurial wrote: post #193
thefreeman wrote: post #167

Earlier quoted context omitted.

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.

In the doc, Google says NSS would need to be added to the base Android image.. so it's not going to be updated any faster than openSSL.

When powering WebView, Chromium on Android uses the Android system-provided OpenSSL library - something not available to applications building with the Android NDK (like Chrome for Android or other Chromium-based Android applications). This helps reduce memory usage by having a single shared library in memory. To accomplish this with NSS, NSS would have to be part of the Android base image - which would still increase memory usage, as most other Android (native) services would still use OpenSSL.

Post reply on HN