Re: [Patch] New item to the Migrating to OpenBSD guide

2015-06-30 Thread lists
 But you’ve done nothing but calling me names nonstop,

I owe you an apology then, and the developers and users who may have
read my ramblings.

 then complaining when people do the same to you. You’re a hypocrite,
 but you clearly don’t realize that, because you keep saying that
 “you’re cool” and “you don’t want to go further” while doing totally
 the opposite.

So calling names is bad and provokes the same, exactly why I was
avoiding reading these parts and intentionally not responding to
the insults targeted at me.

Last night was too late for me, sorry. I thought I finished posting too
and Marc tempted me to explain myself.

 There is an official FAQ especially targeted to Linux users, I am a Linux 
 user, I found some difference between the systems which is not in the FAQ, I 
 thought it could be useful to add a line about it. Period. If that difference 
 is better or worse, I don’t discuss it, only you do.

Most have used Linux at some point, I did too. Comparing a
re-install  rolling release distributions, there is a different
methodology to keep up to date.

I was trying to suggest the whole time that following snapshots
installation and keeping packages updated is the easiest way to achieve
the Linux like rolling release and it does not involve any
recompilation and is fairly easy and straight forward process ideal for
a newcomer or Linux user trying out OpenBSD fresh.

This gives a very low overhead always current state of both base OS and
additional packages. In fact you may not have to install the ports tree
to stay up to date.

As for following stable and current, those would inevitable require
recompilation at some points, which has their own FAQ documents, so
there is no need to complicate the migration FAQ except point to these
FAQs.

Why did you have to mention binary patches at all? It is obvious there
are no such things, but does this belong in the migration FAQ? When
pkg_add -u (updating packages) is exactly the equivalent of a package
manager updates in Linux.

I felt the con point in your publication was a bit unfair and could
scare Linux people away, if they are neither advance in Linux, nor
FreeBSD and obviously new to OpenBSD.

In fact I consider that I got finally settled on a proper upgrade
system just when I got into OpenBSD on a daily basis some many years
ago.

 but treat me with a little respect.

OK, once again, I sincerely want to apologise for the disrespect. I
tend to forget not everyone has a thick skin like I've developed online.



Re: error:0906D064:PEM routines:PEM_read_bio:bad base64

2015-06-30 Thread mxb

I’m sorry but I can’t provide private key. 
It is basically production and not self-signed. Comes from Thawte.

I’m able to produce output from ‘openssl enc -d base64  key’, 
so issue from the link you pointed out is not on my side.

I’m following OpenBSD-current by moving from snap to snap.
I just actually started to deploy SSL acceleration with relayd, so I’m not 
aware on
any prev. working snap. I had older snap which produced this issue, so I moved 
to
up-to-date -CURRENT.

Linux dist which working is FC20, with 'OpenSSL 1.0.1e-fips 11 Feb 2013’.
I have 3 more key/cert pairs from Thawte. Those are OK both on FC20 and 
OpenBSD-current.

Question how do I debug this?
I’m happy to apply any patches for testing.

Br
//mxb

 On 30 jun 2015, at 05:25, Brent Cook bust...@gmail.com wrote:
 
 On Mon, Jun 29, 2015 at 1:22 AM, mxb m...@alumni.chalmers.se wrote:
 Hey,
 
 getting following error on OpenBSD-current as of yesterdays 'cvs up’:
 
 Does this imply that it worked in some earlier version of
 OpenBSD-current? If so, what was the version that worked?
 
 unable to load Private Key
 30008934842236:error:0906D064:PEM routines:PEM_read_bio:bad base64 
 decode:/usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/pem/pem_lib.c:822:
 
 Cmd issued: 'openssl rsa -noout -modulus -in key’
 
 ‘openssl version’: LibreSSL 2.2
 
 This key is OK with openssl on Linux
 
 It's probably silly to ask for a copy of your private key, but could
 you share an example of the input that is failing here? Maybe if you
 can generate a new pem file?
 
 I seem to recall an actually invalid base64 encoding issue that was
 reported last year. Does this seem relevant?
 
 http://tech.openbsd.narkive.com/tHdomkKq/libressl-base64-decoding-error
 
 Saying 'openssl on Linux' doesn't help us much (especially without a
 sample of the input), though something like 'OpenSSL 1.0.1e on Ubuntu
 14.04' might if we had something to test against.
 
 Br
 
 //mxb