[blfs-dev] libressl

2018-04-27 Thread ag
On Mon, Apr 23, at 04:29 Richard Melville wrote:
> On 22 April 2018 at 16:51, Bruce Dubbs  wrote:
>
> I wasn't going to be drawn into this discussion again as it appears that
> Bruce's mind is already made up.
 
Hi Richard, please don't be disappointed.
 
I think first thet the initial work is ten minutes job maximum that consist of:
 
  - changing all the references to openssl to libressl
  
  - rename the openssl page to libressl

  - adjust the variables

  - adjust the instructions

Now,

The second step is to build the applications and libraries that depend on -lssl.
I can bet that few packages will require patches. But even if a package does,
voidlinux has already has it, and here is the source:

git clone https://github.com/voidlinux/void-packages.git 

And then it has to be available in public.
 
Maintainance however is another thing. This has to backport all the patches
from blfs and keep in a sync the differences in the sll relative pages.
Very very simple but time consuming. Personally i would support to host this
project in the LFS infrastructure, if there was a volunteer to maintain that
thing.

But this has to be in git because is the feature and makes collobaration an
a enjoyable game. So because there is no git support, though there were a couple
of quick attempts to convert the codebase lately - if someone has already done 
it
please open a new thread and share the experiences - the natural choise is 
github.
And then a link to that project will be justified. And since the maintainer has 
to
has flexibility he should be a part of the team of course.

> Taking openssh as the starting point, the discussion revolved around which
> of the two TLS libraries, openssl or libressl, should be linked to it.
> Openssh is an openbsd project, so which makes more logical sense: another
> openbsd project: libressl. or openssl from an entirely separate developer
> team with a heavily patched openssh?

The question has been answered already. Nobody denie[ds] the libressl 
superiority.
The question is for us, which adds complexity.

> Another point that I'd like to make is that since 2014 openssh does not
> need *any* additional TLS library as it already contains the AES-CTR,
> ED25519, ECDH, and ChaCha20 cryptos, where elliptic curve is more secure,
> and faster, than RSA/DSA.  An added advantage is that building openssh in
> this manner produces a much smaller code base, which is always better.
> Compiling openssh without the patch, and using -- without-openssl worked
> for me.

Jesus, i didn't knew that, i have years to build by my own openssh, since
i never used, just untill some days when i had to login in higgs to place
a .forward file. Thanks for the info Richard.
 
Then this simplifies the instructions a lot!!! So Bruce you owe to him
here, if you verify that works for you also :-)
 
Rich,

Why don't make you a small patch to help Bruce, who also has to do all the
recent fupdates to Gnome, while he has to maintain LFS, to maintain BLFS, to
maintain the hints project, to maintain and maintain, and also to be a good
professor - as we know he is - and still has to do all these fgome updates.
 
> Richard

Best,
  Αγαθοκλής
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page


[blfs-dev] libressl

2018-04-22 Thread ag
On Tue, Apr 10, at 10:48 ag wrote:
> On Mon, Apr 09, at 02:49 Bruce Dubbs wrote:
> > On 04/09/2018 02:18 PM, Richard Melville wrote:
> > 
> > > Well, I disagree.  Joel Sing has made it clear that he wants libressl to
> > > be a drop-in replacement for openssl.  He has also stated publicly that
> > > he thinks opaque data structures (the basis of the openssl 1.1 API
> > > change) are a good thing.  It's openssl that has broken compatibility
> > > between the 1.0 and the 1.1 APIs, and thus created issues with openssh,
> > > not libressl.  It is, therefore, unrealistic to expect libressl to
> > > conform to the 1.1 API over night.  Clearly, it is going to take some
> > > considerable time.
> > 
> > It has been two years.  How much time do you think is reasonable?
> > 
> > > As a corollary of the need for the original fork, we have seen how many
> > > further openssl security breaches were discovered post fork, none of
> > > which affected libressl.
> > 
> > I wonder why there has been no mass exodus to libressl.  It has been around
> > from 2014.  Do you have any ideas about that?
> > 
> > I did read https://en.wikipedia.org/wiki/LibreSSL
> > It does read like it was written by libressl or bsd developers.
> 
> Tricky. But might be easy finally.
> 
> Theo De Raadt might be an over[something] endless stream of consciousness
> mind that simply can not keep his mouth shut, but is an expert in security.
> 
> I mean, if there is group of people (this time on earth), on who the earth
> could be set its trust to those matters (we are speaking here for the tls 
> stack
> and the secure shell (okey?)) and undeniable by all, that would be him and his
> friends on OpenBSD!
> 
> But as i said the solution at the end might be finally easy.
> 
> We just have to provide two different sets of instructions; one for openssl 
> and
> one for libre. No big deal.
 
Its not that simple as both can not coexist in the same namespace.
 
The thing is that the sonames are identical and much of the API (if all, i don't
know) but that doesn't certainly provides ABI compatibility. So all the 
libraries
and applications should link against the specific library.

Now for us that means some choises:
  
1. we can just add a page for libressl and whereever refers openssl, we have
   additionally refer libressl. But there must be a big fat warning that either
   one or the other. (and also to wait for breakages when linking with libressl,
   for instance I use a patch to build the elinks web browser, but this is not
   going to be a big issue as there is a precedence and a source we can take
   patches)

2. use different namespaces. This should work. But it is not practical and
   can be a little bit complicated.
   We have to talk about using the LD_LIBRARY_PATH, when building and when
   running the applications. Personally someone can take this path but as
   book instructions again is not practical and can end up wasting our time
   anwsering questions

3. another copy of the book that will have libressl as the default tls layer.
   I can do this book in the summer when we are going to build lfs with Dimy,
   but I shouldn't be able to test as I use very little things already and
   its going to be worse with years, but we can do this with my son as an
   educational project

My opininion is the first option or nothing but this is horrible and its a pity.

Best,
  Αγαθοκλής
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page


[blfs-dev] openssh-7.7p1

2018-04-10 Thread ag
On Mon, Apr 09, at 02:49 Bruce Dubbs wrote:
> On 04/09/2018 02:18 PM, Richard Melville wrote:
> 
> > Well, I disagree.  Joel Sing has made it clear that he wants libressl to
> > be a drop-in replacement for openssl.  He has also stated publicly that
> > he thinks opaque data structures (the basis of the openssl 1.1 API
> > change) are a good thing.  It's openssl that has broken compatibility
> > between the 1.0 and the 1.1 APIs, and thus created issues with openssh,
> > not libressl.  It is, therefore, unrealistic to expect libressl to
> > conform to the 1.1 API over night.  Clearly, it is going to take some
> > considerable time.
> 
> It has been two years.  How much time do you think is reasonable?
> 
> > As a corollary of the need for the original fork, we have seen how many
> > further openssl security breaches were discovered post fork, none of
> > which affected libressl.
> 
> I wonder why there has been no mass exodus to libressl.  It has been around
> from 2014.  Do you have any ideas about that?
> 
> I did read https://en.wikipedia.org/wiki/LibreSSL
> It does read like it was written by libressl or bsd developers.

Tricky. But might be easy finally.

Theo De Raadt might be an over[something] endless stream of consciousness
mind that simply can not keep his mouth shut, but is an expert in security.

I mean, if there is group of people (this time on earth), on who the earth
could be set its trust to those matters (we are speaking here for the tls stack
and the secure shell (okey?)) and undeniable by all, that would be him and his
friends on OpenBSD!

But as i said the solution at the end might be finally easy.

We just have to provide two different sets of instructions; one for openssl and
one for libre. No big deal.

>   -- Bruce
>
-- 
Best,
  Αγαθοκλής
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page


[blfs-dev] Anyone building rustc on a ryzen?

2018-04-09 Thread ag
[...]

Very nice discussion guys. Keep in mind that Rust will dominate from
now and on.

Best,
  Αγαθοκλής
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page


[blfs-dev] openssh-7.7p1 and libressl

2018-04-08 Thread ag
On Sun, Apr 08, at 12:48 Tim Tassonis wrote:
> On 04/08/2018 12:42 AM, Bruce Dubbs wrote:
> > It's disturbing that openssh still requires a 60K patch to build with
> > openssl-1.1.0.  openssl-1.1.0. has been in release since August 2916.
> 
> I guess that's probably because they just concentrate on their own libressl.

libressl works fine here in voidlinux for years now.

> Tim
 
Best,
  Αγαθοκλής
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page


[blfs-dev] LFS is about accuracy and concentration.

2018-04-07 Thread Ag, D.E Chatzimanikas
Here is an innocent example.

On Sat, Apr 07, at 05:04 Ag, D.E Chatzimanikas wrote:
 
> I'm running mutt here, a quite recent version ...

That means at least a > 1.9.0.

But if you look at the headers of this same email in the "Mailing List
Netiquette" thread, you will see that was yes, it was send by mutt, but
not from a "quite recent version". Here i'm posting this for you.

   User-Agent: Mutt/1.8.0 (2017-02-23)

(that is because it was send by an old machine, but it's not that point
here)

And yes, as most of us, I issued one time in my life a careless "rm -rf"
with catastrofic results. So lesson number one to all of us.

Concentration.

Best,
  Αγαθοκλής
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page


[blfs-dev] Mailing List Netiquette.

2018-04-06 Thread Ag, D.E Chatzimanikas
This is to point to the basic etiquette for mailing lists.

http://linuxfromscratch.org/faq/#netiquette

Learn more:

https://en.wikipedia.org/wiki/Etiquette_in_technology

-- 
Best,
  Αγαθοκλής
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page


[blfs-dev] Contributing to LFS and BLFS books.

2018-04-06 Thread Ag, D.E Chatzimanikas
This is to point out two existing documents, that provide more than
enough information for people that would like to contribute on LFS
books development.

Editors Guide:

http://www.linuxfromscratch.org/blfs/edguide/

Hacking the Books:

http://wiki.linuxfromscratch.org/blfs/wiki/Hacking

(though both documents are guides to helps you hack on the BLFS book,
the same pretty much applies for the LFS book)

Happy Hacking.

-- 
Best,
  Αγαθοκλής
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page