Re: xSSL stuff
On 13/06/2014, at 14:23, Christian Pedaschus open...@matt-schwarz.com wrote: One could have said the same about OpenSSH... or not? That doesn't even make any sense. What i was trying to say: if OpenBSD does it right, then (maybe) the others will follow... It would be totally ok if OpenSSH programs were all converted to longopts-only, and XML config files, right? After all, it won't take long to fix all your cron jobs/scripts/clusterssh/... That's approximately what you're suggesting folks do with the SSL libraries. John
Re: xSSL stuff
On Fri, Jun 13, 2014 at 05:59:59AM +0200, Christian Pedaschus wrote: On Thu, 12 Jun 2014 23:51:58 -0400 Brad Smith b...@comstyle.com wrote: On 12/06/14 11:43 PM, Christian Pedaschus wrote: wouldn't it be a feature? less warts, less bugs, less features, less compatible, but secure? What good is having a brand new from scratch API when almost nothing uses it? There are thousands of apps / libraries using OpenSSL. Are YOU going to go to each and every project and write SSL code for each respective project to add support for this from scratch API? One could have said the same about OpenSSH... or not? not. OpenSSH is an implementation of a protocol in a program. OpenSSH is not a library to be used by other programs. -Otto
Re: xSSL stuff
On 2014-06-13, Christian Pedaschus open...@matt-schwarz.com wrote: wouldn't it be a feature? less warts, less bugs, less features, less compatible, but secure? LibreSSL is trying to improve things for programs written against the OpenSSL API, there are other projects who have implemented new cleaner APIs (e.g. Botan and the XySSL forks PolarSSL and TropicSSL) though to date they're not especially widely used. There's a place for both approaches, but there's absolutely no way all the existing OpenSSL dependent code will be ported to a different API.
Re: xSSL stuff
Christian Pedaschus open...@matt-schwarz.com wrote: On Tue, 10 Jun 2014 12:14:46 -0600 Theo de Raadt dera...@cvs.openbsd.org wrote: I was reading stuff in misc@ about OpenSSL broken things. I see people from OpenBSD started LibreSSL project and they are forking OpenSSL and remove the bad code. This is past, but I see more and more lesions are discovered. It may be a stupid question, but having all these, isn't more efficient to start LibreSSL from zero? Impossible. The OpenSSL API was built up through accretion over almost 2 decades. It is fat, bloated, repetitive, and tricky. In general, application authors have chosen to use the first API's they spot which provide the functionality they need. As a result, almost all of the bloated API is potentially used in the greater ecosystem. It is quite simply impossible to reinvent this particular wheel. Any effort to reinvent it would be highly incompatible. Features and warts are too closely coupled. wouldn't it be a feature? less warts, less bugs, less features, less compatible, but secure? how many ciphers do we need, to retrieve websites/mails over a secure channel? (i'm not a crypto guy, would love to get an answer. my bet: 1). are exotic 1995 devices really worth the trouble? regards, chris First you want LibreSSL to be widely used. Then you get to deprecate bad features. Trying to depracate bad features in another project is doomed to fail. It would be like WINE announcing that certain Win32 APIs are gone. In the event that LibreSSL is never used by anyone except OpenBSD, removing bad features is just going to require us to get OpenSSL from packages/ports. -- Martin
Re: xSSL stuff
On Tue, 10 Jun 2014 12:14:46 -0600 Theo de Raadt dera...@cvs.openbsd.org wrote: I was reading stuff in misc@ about OpenSSL broken things. I see people from OpenBSD started LibreSSL project and they are forking OpenSSL and remove the bad code. This is past, but I see more and more lesions are discovered. It may be a stupid question, but having all these, isn't more efficient to start LibreSSL from zero? Impossible. The OpenSSL API was built up through accretion over almost 2 decades. It is fat, bloated, repetitive, and tricky. In general, application authors have chosen to use the first API's they spot which provide the functionality they need. As a result, almost all of the bloated API is potentially used in the greater ecosystem. It is quite simply impossible to reinvent this particular wheel. Any effort to reinvent it would be highly incompatible. Features and warts are too closely coupled. wouldn't it be a feature? less warts, less bugs, less features, less compatible, but secure? how many ciphers do we need, to retrieve websites/mails over a secure channel? (i'm not a crypto guy, would love to get an answer. my bet: 1). are exotic 1995 devices really worth the trouble? regards, chris
Re: xSSL stuff
On 12/06/14 11:43 PM, Christian Pedaschus wrote: On Tue, 10 Jun 2014 12:14:46 -0600 Theo de Raadt dera...@cvs.openbsd.org wrote: I was reading stuff in misc@ about OpenSSL broken things. I see people from OpenBSD started LibreSSL project and they are forking OpenSSL and remove the bad code. This is past, but I see more and more lesions are discovered. It may be a stupid question, but having all these, isn't more efficient to start LibreSSL from zero? Impossible. The OpenSSL API was built up through accretion over almost 2 decades. It is fat, bloated, repetitive, and tricky. In general, application authors have chosen to use the first API's they spot which provide the functionality they need. As a result, almost all of the bloated API is potentially used in the greater ecosystem. It is quite simply impossible to reinvent this particular wheel. Any effort to reinvent it would be highly incompatible. Features and warts are too closely coupled. wouldn't it be a feature? less warts, less bugs, less features, less compatible, but secure? What good is having a brand new from scratch API when almost nothing uses it? There are thousands of apps / libraries using OpenSSL. Are YOU going to go to each and every project and write SSL code for each respective project to add support for this from scratch API? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: xSSL stuff
On Thu, 12 Jun 2014 23:51:58 -0400 Brad Smith b...@comstyle.com wrote: On 12/06/14 11:43 PM, Christian Pedaschus wrote: wouldn't it be a feature? less warts, less bugs, less features, less compatible, but secure? What good is having a brand new from scratch API when almost nothing uses it? There are thousands of apps / libraries using OpenSSL. Are YOU going to go to each and every project and write SSL code for each respective project to add support for this from scratch API? One could have said the same about OpenSSH... or not?
Re: xSSL stuff
On 12/06/14 11:59 PM, Christian Pedaschus wrote: On Thu, 12 Jun 2014 23:51:58 -0400 Brad Smith b...@comstyle.com wrote: On 12/06/14 11:43 PM, Christian Pedaschus wrote: wouldn't it be a feature? less warts, less bugs, less features, less compatible, but secure? What good is having a brand new from scratch API when almost nothing uses it? There are thousands of apps / libraries using OpenSSL. Are YOU going to go to each and every project and write SSL code for each respective project to add support for this from scratch API? One could have said the same about OpenSSH... or not? That doesn't even make any sense. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Fw: xSSL stuff
ups, forgot to cc the list... On Thu, 12 Jun 2014 23:59:46 -0400 Brad Smith b...@comstyle.com wrote: On 12/06/14 11:59 PM, Christian Pedaschus wrote: On Thu, 12 Jun 2014 23:51:58 -0400 Brad Smith b...@comstyle.com wrote: On 12/06/14 11:43 PM, Christian Pedaschus wrote: wouldn't it be a feature? less warts, less bugs, less features, less compatible, but secure? What good is having a brand new from scratch API when almost nothing uses it? There are thousands of apps / libraries using OpenSSL. Are YOU going to go to each and every project and write SSL code for each respective project to add support for this from scratch API? One could have said the same about OpenSSH... or not? That doesn't even make any sense. What i was trying to say: if OpenBSD does it right, then (maybe) the others will follow... not? ok! Fine for me, just threw my 2 cents into the discussion Just keep going, i'm sure you guys do the right thing! regards, chris
xSSL stuff
I was reading stuff in misc@ about OpenSSL broken things. I see people from OpenBSD started LibreSSL project and they are forking OpenSSL and remove the bad code. This is past, but I see more and more lesions are discovered. It may be a stupid question, but having all these, isn't more efficient to start LibreSSL from zero? I know OpenBSD is short on staff, but the effort to start from zero code could be less than fix the old code, I think. Or could it be that the OpenSSL code is not so broken? Can someone post here a percent of usable code? Thanks.
Re: xSSL stuff
I was reading stuff in misc@ about OpenSSL broken things. I see people from OpenBSD started LibreSSL project and they are forking OpenSSL and remove the bad code. This is past, but I see more and more lesions are discovered. It may be a stupid question, but having all these, isn't more efficient to start LibreSSL from zero? Impossible. The OpenSSL API was built up through accretion over almost 2 decades. It is fat, bloated, repetitive, and tricky. In general, application authors have chosen to use the first API's they spot which provide the functionality they need. As a result, almost all of the bloated API is potentially used in the greater ecosystem. It is quite simply impossible to reinvent this particular wheel. Any effort to reinvent it would be highly incompatible. Features and warts are too closely coupled. I know OpenBSD is short on staff, but the effort to start from zero code could be less than fix the old code, I think. Or could it be that the OpenSSL code is not so broken? Can someone post here a percent of usable code? Our team does not have the skill to rewrite this and be 100% compatible. We think we have enough sensibility for a different process: We will refine the codebase. First we will remove things noone uses. Then, we will clean up the issues as we see them, emphasizing care and awareness of what mainstream applications use. Finally, we would like to apply light pressure against the worst least used APIs, to convince application's to move to safer APIs. Shrink the API exposure, simplify. But that won't happen today. Please be patient...
