Debian Bug report logs - #754513
RFP: libressl -- SSL library, forked from OpenSSL

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Toni Mueller <support@oeko.net>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sat, 12 Jul 2014 00:06:27 +0200

Package: wnpp
Severity: wishlist
Owner: Toni Mueller <toni@debian.org>

* Package name    : libressl
  Version         : 2.0.0
  Upstream Author : The OpenBSD project, the OpenSSL project et al.
* URL             : http://www.libressl.org/
* License         : BSD, OpenSSL, SSLeay, Public Domain.
  Programming Lang: C
  Description     : SSL library, forked from OpenSSL


LibreSSL strives to maintain API compatibility with OpenSSL, but
do away with all the cruft.

After a long series of OpenSSL problems, recently highlighted by
the infamous Heartbleed bug, a group inside OpenBSD decided to
fork OpenSSL and adapt the code to modern coding standards.
Along the way, a lot of compatibility with older architectures
and toolchains was discarded.

Message #10 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Steven Chamberlain <steven@pyro.eu.org>

To: 754513@bugs.debian.org

Cc: "debian-bsd@lists.debian.org" <debian-bsd@lists.debian.org>, 754513-submitter@bugs.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sat, 12 Jul 2014 02:09:48 +0100

[Message part 1 (text/plain, inline)]

This is good to see already :)

I expect it builds fine on GNU/Linux, with GCC and Clang, unless
hardening options are used, then these warnings would be treated as errors:

> In file included from md5/md5_locl.h:98:0,
>                  from md5/md5_dgst.c:60:
> md5/md5_dgst.c: In function 'md5_block_data_order':
> ./md32_common.h:237:66: warning: right-hand operand of comma expression has no effect [-Wunused-value]
>  #  define HOST_c2l(c,l) ((l)=*((const unsigned int *)(c)), (c)+=4, l)
>                                                                   ^
> md5/md5_dgst.c:107:2: note: in expansion of macro 'HOST_c2l'
>   HOST_c2l(data,l); X( 0)=l;  HOST_c2l(data,l); X( 1)=l;
>   ^

> ./md32_common.h:213:41: warning: right-hand operand of comma expression has no effect [-Wunused-value]
>      l|=(((unsigned long)(*((c)++)))    ),  \
>                                          ^
> sha/sha256.c:245:3: note: in expansion of macro 'HOST_c2l'
>    HOST_c2l(data,l); T1 = X[0] = l;  ROUND_00_15(0,a,b,c,d,e,f,g,h);
>    ^

We'd want to configure with --disable-silent-rules, if debhelper scripts
don't already do that.

Compiling on GNU/kFreeBSD is possible (and potentially GNU/Hurd) but
requires the attached patch *and* a solution for getentropy:

1. try to use getentropy_linux.c - but would have to disable use of
Linux-specific sysctls and headers;  it is dangerous to rely on only
/dev/random, so we should implement replacement sysctls to use on
FreeBSD - that could be a bit messy

2. create a new getentropy_freebsd.c - but seems silly as FreeBSD itself
does not need it (see solution 3);  also does not help GNU/Hurd

3. (my preference) link with libbsd, which already provides a
arc4random_buf and so getentropy is not needed at all - WARNING: the
libbsd arc4random implementation still uses RC4 at the moment (as on
FreeBSD), but OpenBSD has already changed it to use ChaCha20 (see Bug
#747671);  we'd also want to make sure libbsd's entropy gathering is at
least as robust as in getentropy_linux.c

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

[libressl-kfreebsd.patch (text/x-patch, attachment)]

Message #18 received at 754513@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: 754513@bugs.debian.org

Cc: debian-devel@lists.debian.og

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sat, 12 Jul 2014 07:43:44 +0200

[Message part 1 (text/plain, inline)]

On Jul 12, Toni Mueller <support@oeko.net> wrote:

> * Package name    : libressl
I am highly doubtful at best.

What are your plans exactly?
Would it have the same SONAME of openssl and conflict+provide it?
Would it be a totally different library which packages would 
build-depend on?
Which packages are supposed to use it?

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #23 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be>

To: Toni Mueller <support@oeko.net>, 754513@bugs.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sat, 12 Jul 2014 13:25:47 +0200

On Sat, Jul 12, 2014 at 12:06:27AM +0200, Toni Mueller wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Toni Mueller <toni@debian.org>
> 
> * Package name    : libressl
>   Version         : 2.0.0
>   Upstream Author : The OpenBSD project, the OpenSSL project et al.
> * URL             : http://www.libressl.org/
> * License         : BSD, OpenSSL, SSLeay, Public Domain.
>   Programming Lang: C
>   Description     : SSL library, forked from OpenSSL
> 
> 
> LibreSSL strives to maintain API compatibility with OpenSSL, but
> do away with all the cruft.
> 
> After a long series of OpenSSL problems, recently highlighted by
> the infamous Heartbleed bug, a group inside OpenBSD decided to
> fork OpenSSL and adapt the code to modern coding standards.
> Along the way, a lot of compatibility with older architectures
> and toolchains was discarded.

I assume that since it's named libressl that the soname will
contain "libressl.so"?  What about the crypto library?
librecrypto.so?

What are you doing with the binaries, include files, man pages,
...?  Will they conflict with the ones from openssl?

If you're interested in maintaining such a package, why did you
never respond to the RFH for openssl?


Kurt

Message #28 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Toni Mueller <toni@debian.org>

To: Kurt Roeckx <kurt@roeckx.be>, 754513@bugs.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sat, 12 Jul 2014 13:53:45 +0200

Hi Kurt,

On Sat, Jul 12, 2014 at 01:25:47PM +0200, Kurt Roeckx wrote:
> What are you doing with the binaries, include files, man pages,
> ...?  Will they conflict with the ones from openssl?

my intention is to package this stuff so one can have both openssl and
libressl installed in parallel. libressl currently has libraries with
these sonames:

libssl.so.26
libcrypto.so.29
 
> If you're interested in maintaining such a package, why did you
> never respond to the RFH for openssl?

There are a number of reasons for that, but one has been that I was
unhappy about the perceived 'closedness' of the project, and my general
feeling that I would like to have an alternative to openssl, which has
been festering for several years now. For a while, I was hoping for
libgnutls, but after the wakeup call, sent by heartbeat, I tried to
figuere out which would be the best way forward, and I generally trust
the OpenBSD folks, who are the vast majority behind LibreSSL, much more
with respect to their ability to understand security and pursuing a "no
backdoors" philosophy than most other people. FWIW, I have well over a
decade of very good experience with OpenBSD, although I prefer Debian
for most purposes, including a general slant towards "copyleft" (GPL)
instead of "copyright" (BSD). They simply provide one of the, or the
one, most viable alternatives to OpenSSL, thus helping to break down the
obviously unhealthy monopoly that currently is OpenSSL.

@Marco et al: I'll answer your other questions RSN, but the first
portable release has only appeared yesterday, so it'll take some time
until the dust settles. And no, I don't think we should go into
production and switch to LibreSSL right now. But we should definitely
have it.

@Kurt: That should imho go to devel@, not only to you and the BTS.


Kind regards,
--Toni++

Message #33 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be>

To: Toni Mueller <toni@debian.org>

Cc: 754513@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sat, 12 Jul 2014 14:15:13 +0200

On Sat, Jul 12, 2014 at 01:53:45PM +0200, Toni Mueller wrote:
> 
> Hi Kurt,
> 
> On Sat, Jul 12, 2014 at 01:25:47PM +0200, Kurt Roeckx wrote:
> > What are you doing with the binaries, include files, man pages,
> > ...?  Will they conflict with the ones from openssl?
> 
> my intention is to package this stuff so one can have both openssl and
> libressl installed in parallel. libressl currently has libraries with
> these sonames:
> 
> libssl.so.26
> libcrypto.so.29

I don't really like it, since it could potentionally clash with
the ones provided by openssl.  But it seems unlikely that openssl
will ever use that as soname.

I had the feeling openbsd didn't care much about ABI stability,
and that being at 26 and 29 already doesn't give me a good feeling
either.  I hope you don't have to go and change the binary package
names each time you upload a new version.

> > If you're interested in maintaining such a package, why did you
> > never respond to the RFH for openssl?
> 
> There are a number of reasons for that, but one has been that I was
> unhappy about the perceived 'closedness' of the project

I was never very happy with it either.  But it has very recently
changed, and I think it's going in the right direction.  I'm now
also in the openssl development team.

> I generally trust
> the OpenBSD folks, who are the vast majority behind LibreSSL, much more
> with respect to their ability to understand security and pursuing a "no
> backdoors" philosophy than most other people.

I'm not really sure what you mean by this.  I'm pretty sure the
openssl development team has a pretty good understanding of
security and I don't see anybody adding a backdoor in it.

> FWIW, I have well over a
> decade of very good experience with OpenBSD

Not everybody has the same experience with them.

> although I prefer Debian
> for most purposes, including a general slant towards "copyleft" (GPL)
> instead of "copyright" (BSD). They simply provide one of the, or the
> one, most viable alternatives to OpenSSL, thus helping to break down the
> obviously unhealthy monopoly that currently is OpenSSL.

I think GnuTLS is actually a better alternative and wish there
were more people developing and using it.

> @Kurt: That should imho go to devel@, not only to you and the BTS.

I did intend to send it to the list, but forgot to Cc it, so doing
that now.


Kurt

Message #38 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be>

To: Toni Mueller <toni@debian.org>

Cc: 754513@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sat, 12 Jul 2014 14:22:57 +0200

On Sat, Jul 12, 2014 at 02:15:13PM +0200, Kurt Roeckx wrote:
> On Sat, Jul 12, 2014 at 01:53:45PM +0200, Toni Mueller wrote:
> > There are a number of reasons for that, but one has been that I was
> > unhappy about the perceived 'closedness' of the project
> 
> I was never very happy with it either.  But it has very recently
> changed, and I think it's going in the right direction.  I'm now
> also in the openssl development team.

I'm not sure that you saw this, but we recently published a
roadmap document:
https://www.openssl.org/about/roadmap.html


Kurt

Message #43 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Toni Mueller <toni@debian.org>

To: 754513@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sat, 12 Jul 2014 14:46:45 +0200

Hi Kurt,

[ I have trimmed the Cc list - we are all on devel@, anyway, right? ]

On Sat, Jul 12, 2014 at 02:15:13PM +0200, Kurt Roeckx wrote:
> On Sat, Jul 12, 2014 at 01:53:45PM +0200, Toni Mueller wrote:
> > On Sat, Jul 12, 2014 at 01:25:47PM +0200, Kurt Roeckx wrote:
> > > What are you doing with the binaries, include files, man pages,
> > > ...?  Will they conflict with the ones from openssl?
> > 
> > my intention is to package this stuff so one can have both openssl and
> > libressl installed in parallel. libressl currently has libraries with
> > these sonames:
> > 
> > libssl.so.26
> > libcrypto.so.29
> 
> I don't really like it, since it could potentionally clash with
> the ones provided by openssl.  But it seems unlikely that openssl
> will ever use that as soname.
> 
> I had the feeling openbsd didn't care much about ABI stability,
> and that being at 26 and 29 already doesn't give me a good feeling
> either.  I hope you don't have to go and change the binary package
> names each time you upload a new version.

Actually, these version numbers typically correspond with the version
numbers in the rest of their system. As libressl is currently under
heavy development, it is imho not to be expected to have that stable ABI
you are asking for. OTOH, one guy already switched his entire Linux
system over, so far with no visible adverse effects.

> I was never very happy with it either.  But it has very recently
> changed, and I think it's going in the right direction.  I'm now
> also in the openssl development team.

Good. That does help to improve my trust with it.

> I'm not really sure what you mean by this.  I'm pretty sure the
> openssl development team has a pretty good understanding of
> security and I don't see anybody adding a backdoor in it.

Ok, but for whatever reason, they have an imho not as shiny track
record, as has OpenBSD. Which is no wonder, given all the revelations we
have had recently, but hey, sometimes one has to make a decision.

> > FWIW, I have well over a decade of very good experience with OpenBSD
> 
> Not everybody has the same experience with them.

Yes. Not everybody has an intention to use LibreSSL, either, but
regarding crypto, they usually know their stuff well above average. See
eg. their OpenSSH, which has seen very widespread adoption.

> I think GnuTLS is actually a better alternative and wish there
> were more people developing and using it.

But developing GnuTLS is a full-time job, and then there's the control
problem with the FSF - you are certainly aware about the problems the
original upstream ran into when he wanted to break loose from the FSF
(for a reason I have forgotten). LibreSSL is a much lower-hanging fruit,
as it is supposed to be mostly, or entirely, plug-compatible with
OpenSSL. To me, the playing field largely looks like this atm:

 * GnuTLS, with an API incompatible with OpenSSL, thus requiring huge
   amounts of work to make significant use of it.
 * MatrixSSL, which once had a dubious license, and which still did not
   come out too well in the SSL lib comparison I recently saw (see the
   list archive),
 * the now newly staffed OpenSSL project, with their mixed track
   record (eg. "FIPS"), and now
 * LibreSSL, which sounds much like an OpenSSL on a diet, and with some
   exercise, and promising thrust behind it, but mostly simply a
   drop-in.

And I guess the BoringSSL people will chime in sooner or later, too...


Kind regards,
--Toni++

Message #48 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Toni Mueller <toni@debian.org>

To: Marco d'Itri <md@Linux.IT>

Cc: 754513@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sat, 12 Jul 2014 15:04:30 +0200

Hi,

On Sat, Jul 12, 2014 at 07:43:44AM +0200, Marco d'Itri wrote:
> On Jul 12, Toni Mueller <support@oeko.net> wrote:
> > * Package name    : libressl
> I am highly doubtful at best.

in which respect, and why?

> What are your plans exactly?

My plan is to first build the package(s) and upload to experimental, so
people can start to play with it.

> Would it have the same SONAME of openssl and conflict+provide it?

I would like to make it co-installable with OpenSSL, but in general,
this should be a drop-in replacement until APIs really diverge in a
visible way. Yes, it would provide 'openssl', but I intend to place them
into a different directory, so you might have to use LD_PATH to get
them. Whether it has to conflict with openssl, I'll figure out that
later, if otherwise the case would arise that a binary might get libssl
from one package, and libcrypto from the other.

So far, it looks like a recompile could be necessary. But since the
upstream package has seen the light of day only yesterday (see
http://article.gmane.org/gmane.os.openbsd.announce/186 for the
announcement), things are not yet stable. For the technical side of the
discussion, you can read http://dir.gmane.org/gmane.os.openbsd.tech).

> Would it be a totally different library which packages would 
> build-depend on?

Packages currently build-depending on openssl should be able to
build-depend on "openssl-dev | libressl-dev". For recent versions of
OpenSSH, it already works, and another user writes: "Just switched my
slackware 14.1 box over to libressl instead of openssl and it's working
great so far, no problems at all." So I guess usability is already good.
But imho, it does have to stand the test of time, and receive
independent review, and much more exposure. Which is one reason why I
think it is a very good idea to expose it to the Debian and related
communities.


Kind regards,
--Toni++

Message #53 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Steven Chamberlain <steven@pyro.eu.org>

To: Toni Mueller <toni@debian.org>, 754513@bugs.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sat, 12 Jul 2014 15:01:51 +0100

On Jul 12, Toni Mueller <support@oeko.net> wrote:
> On Sat, Jul 12, 2014 at 07:43:44AM +0200, Marco d'Itri wrote:
> > On Jul 12, Toni Mueller <support@oeko.net> wrote:
> > > * Package name    : libressl
> > I am highly doubtful at best.
> 
> in which respect, and why?

I think some people are jumping ahead to "oh no!  we're replacing
OpenSSL?".  That's something to be have some rough plan for in case
we eventually want to do that.  But for now I don't think it's a
reason not to package it or even allow it into sid/testing.

> > What are your plans exactly?
> 
> My plan is to first build the package(s) and upload to experimental, so
> people can start to play with it.

It is definitely an interesting piece of software, with some different
design choices being made here and there.  It even adds some new
features (new ciphers and elliptic curves for example) and the utilities
are useful standalone (such as for an SSL CA).

People can start to play around with it and maybe to try to rebuild
packages against it locally.  It couldn't be a drop-in replacement
for OpenSSL's libssl and libcrypto because the ABI will differ.  The
source API is being kept as similar as possible so in theory:

> Packages currently build-depending on openssl should be able to
> build-depend on "openssl-dev | libressl-dev".

that sounds like it should just work.  Or otherwise, it could reveal
if a package uses some 'unsafe' part of the API that OpenBSD has removed
during their cleanup.  Any incompatibilities or run-time differences are
likely interesting to both SSL libraries as it could indicate a bug
somewhere.

Probably only a minority of people would want to rebuild many packages
on their system against LibreSSL.  But having it packaged, and
co-installable helps people who want to do this.  Similarly there is
support in the Exim packaging to rebuild with OpenSSL instead of GnuTLS.

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

Message #58 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Thomas Goirand <zigo@debian.org>

To: Toni Mueller <toni@debian.org>, 754513@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sun, 13 Jul 2014 11:52:24 +0800

On 07/12/2014 08:46 PM, Toni Mueller wrote:
> As libressl is currently under
> heavy development, it is imho not to be expected to have that stable ABI
> you are asking for.

Well, I don't agree with this view. If LibreSSL pretends to be a
replacement for OpenSSL, then they should care about being ABI
compatible, so we can easily switch from one implementation to the
other. Just like for MariaDB / MySQL in fact (not sure if these are
still ABI compatible though). If that's not the case, then it looses a
lot of its purpose. As Kurt wrote, GNUTLS becomes a better alternative then.

> OTOH, one guy already switched his entire Linux
> system over, so far with no visible adverse effects.

And then? This gives no clue if he had to rebuild everything that
build-depended on OpenSSL...


On 07/13/2014 01:15 AM, Russ Allbery wrote:
> If you start using both for different packages, then you end up with
> shared libraries conflicting over which libssl they want to use, and
> then bad things start happening.

Exactly! I fully agree with you on this. This reminds me issues I had
with mod-log-sql linked to MySQL and php as well, and when they were
built against different versions... BOOM! I certainly do *not* want this
kind of things to happen in Debian. Therefore, I'd very much prefer if
we used OpenSSL *or* LibreSSL, but not have the choice between the 2,
otherwise, that's a recipe for disaster.

Please don't upload LibreSSL to Sid *ever*, unless we collectively
decide that we are switching away from OpenSSL (and for which a
discussion would have to start).

Cheers,

Thomas Goirand (zigo)

Message #63 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Matthias Urlichs <matthias@urlichs.de>

To: debian-devel@lists.debian.org

Cc: 754513@bugs.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sun, 13 Jul 2014 08:17:51 +0200

Hi,

Thomas Goirand:
> Well, I don't agree with this view. If LibreSSL pretends to be a
> replacement for OpenSSL, then they should care about being ABI
> compatible, so we can easily switch from one implementation to the
> other.

That depends. If the ABI in question includes calls or constants which are
the security equivalent of gets() or scanf("%s") or …, then no.

> As Kurt wrote, GNUTLS becomes a better alternative then.

Does gnutls have an openssl shim which actually works as a generic
replacement? I dimly recall a couple of not-so-nice incompatibilities …

> Therefore, I'd very much prefer if we used OpenSSL *or* LibreSSL, but not
> have the choice between the 2, otherwise, that's a recipe for disaster.
> 
Well …

> Please don't upload LibreSSL to Sid *ever*, unless we collectively
> decide that we are switching away from OpenSSL (and for which a
> discussion would have to start).
> 
… while IMHO it's possible to safely mix openssl and libressl if we prepare
for that (i.e. make sure that _everything_ in libressl is only exported 
with properly versioned symbols), again IMHO the time and effort required
for _that_ would be better spent evaluating the changes both projects made
and then deciding which of the two shall be in Debian.

Both efforts have started fairly recently, so it's kind of premature to do
that now; and while IANARTM (Release Team Member) transitioning the whole
of Debian to libressl closer to the release would not be a good idea even
if we decide it's (going to be) the better alternative.

-- 
-- Matthias Urlichs

Message #68 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Jeroen Dekkers <jeroen@dekkers.ch>

To: 754513@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sun, 13 Jul 2014 12:22:49 +0200

At Sat, 12 Jul 2014 14:46:45 +0200,
Toni Mueller wrote:
> On Sat, Jul 12, 2014 at 02:15:13PM +0200, Kurt Roeckx wrote:
> 
> > I'm not really sure what you mean by this.  I'm pretty sure the
> > openssl development team has a pretty good understanding of
> > security and I don't see anybody adding a backdoor in it.
> 
> Ok, but for whatever reason, they have an imho not as shiny track
> record, as has OpenBSD. Which is no wonder, given all the revelations we
> have had recently, but hey, sometimes one has to make a decision.

OpenSSL was part of OpenBSD before they created the LibreSSL fork, so
how isn't OpenSSL part of the OpenBSD track record?

> > I think GnuTLS is actually a better alternative and wish there
> > were more people developing and using it.
> 
> But developing GnuTLS is a full-time job, and then there's the control
> problem with the FSF - you are certainly aware about the problems the
> original upstream ran into when he wanted to break loose from the FSF
> (for a reason I have forgotten). LibreSSL is a much lower-hanging fruit,
> as it is supposed to be mostly, or entirely, plug-compatible with
> OpenSSL. To me, the playing field largely looks like this atm:
> 
>  * GnuTLS, with an API incompatible with OpenSSL, thus requiring huge
>    amounts of work to make significant use of it.

It depends on how you look at it. If you see the OpenSSL API as
something that isn't really well designed then other libraries not
copying the API is actually a good thing.

>  * MatrixSSL, which once had a dubious license, and which still did not
>    come out too well in the SSL lib comparison I recently saw (see the
>    list archive),
>  * the now newly staffed OpenSSL project, with their mixed track
>    record (eg. "FIPS"), and now
>  * LibreSSL, which sounds much like an OpenSSL on a diet, and with some
>    exercise, and promising thrust behind it, but mostly simply a
>    drop-in.

You forget one of the big problems with OpenSSL that LibreSSL doesn't
fix: the license. It actually makes the mess even bigger, given that
some of the GPL exceptions only talk about "the OpenSSL library" and
don't exempt OpenSSL-derived code. So even if LibreSSL is a drop-in
for OpenSSL we can't replace OpenSSL with LibreSSL for those projects.

You also forget to list two other TLS libraries:

* NSS, in my opinion the biggest downside of NSS is that it includes
  NSPR. This both increases the code size a lot and makes the API less
  nice if I remember correctly.

* PolarSSL, which I really like from a technical point of
  view. Featurewise it is pretty complete (the only major feature it
  doesn't implement is DTLS AFAICS), while being one tenth the size of
  OpenSSL / GnuTLS:
  https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Code_size_and_dependencies
  PolarSSL is also used by OpenVPN-NL, the hardened OpenVPN version
  that is used by the Dutch government.
  The downsides are that it looks like it doesn't have a stable API
  and contributing needs copyright assignment because it is
  dual-licensed.


Kind regards,

Jeroen Dekkers

Message #73 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Thomas Goirand <zigo@debian.org>

To: debian-devel@lists.debian.org

Cc: 754513@bugs.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sun, 13 Jul 2014 18:29:47 +0800

On 07/13/2014 02:17 PM, Matthias Urlichs wrote:
> Does gnutls have an openssl shim which actually works as a generic
> replacement? I dimly recall a couple of not-so-nice incompatibilities

As much as I understand, it's a complete alternative with a different
API, I don't think there's a compatibility layer (though I didn't look).

> while IMHO it's possible to safely mix openssl and libressl if we prepare
> for that (i.e. make sure that _everything_ in libressl is only exported 
> with properly versioned symbols), again IMHO the time and effort required
> for _that_ would be better spent evaluating the changes both projects made
> and then deciding which of the two shall be in Debian.
> 
> Both efforts have started fairly recently, so it's kind of premature to do
> that now; and while IANARTM (Release Team Member) transitioning the whole
> of Debian to libressl closer to the release would not be a good idea even
> if we decide it's (going to be) the better alternative.

I fully agree with what's above.

Thomas

Message #78 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Matthias Urlichs <matthias@urlichs.de>

Cc: debian-devel@lists.debian.org, 754513@bugs.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sun, 13 Jul 2014 19:54:59 +0900

On Sun, Jul 13, 2014 at 08:17:51AM +0200, Matthias Urlichs wrote:
> Hi,
> 
> Thomas Goirand:
> > Well, I don't agree with this view. If LibreSSL pretends to be a
> > replacement for OpenSSL, then they should care about being ABI
> > compatible, so we can easily switch from one implementation to the
> > other.
> 
> That depends. If the ABI in question includes calls or constants which are
> the security equivalent of gets() or scanf("%s") or …, then no.
> 
> > As Kurt wrote, GNUTLS becomes a better alternative then.
> 
> Does gnutls have an openssl shim which actually works as a generic
> replacement? I dimly recall a couple of not-so-nice incompatibilities …
> 
> > Therefore, I'd very much prefer if we used OpenSSL *or* LibreSSL, but not
> > have the choice between the 2, otherwise, that's a recipe for disaster.
> > 
> Well …
> 
> > Please don't upload LibreSSL to Sid *ever*, unless we collectively
> > decide that we are switching away from OpenSSL (and for which a
> > discussion would have to start).
> > 
> … while IMHO it's possible to safely mix openssl and libressl if we prepare
> for that (i.e. make sure that _everything_ in libressl is only exported 
> with properly versioned symbols)

Contrary to what you seem to believe, this only really works if *both*
libraries have versioned symbols. Otherwise, you can end up with
libraries linked against the unversioned one using symbols from the
versioned one at run time when both are loaded in the same address
space.

Mike

Message #83 received at 754513@bugs.debian.org (full text, mbox, reply):

From: "Bernhard R. Link" <brlink@debian.org>

To: debian-devel@lists.debian.org

Cc: Matthias Urlichs <matthias@urlichs.de>, 754513@bugs.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sun, 13 Jul 2014 13:11:33 +0200

* Mike Hommey <mh@glandium.org> [140713 12:55]:
> > … while IMHO it's possible to safely mix openssl and libressl if we prepare
> > for that (i.e. make sure that _everything_ in libressl is only exported 
> > with properly versioned symbols)
> 
> Contrary to what you seem to believe, this only really works if *both*
> libraries have versioned symbols. Otherwise, you can end up with
> libraries linked against the unversioned one using symbols from the
> versioned one at run time when both are loaded in the same address
> space.

Actually, "both having versioned symbols" is not enough.
It is either "both must always have had versioned symbols" or
"both must have versioned symbols now and every binary linked against
either must have been built (or rebuilt) after the symbols got
versioned".

	Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC

Message #88 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Matthias Urlichs <matthias@urlichs.de>

To: debian-devel@lists.debian.org, 754513@bugs.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sun, 13 Jul 2014 14:02:18 +0200

Hi,

Bernhard R. Link:
> * Mike Hommey <mh@glandium.org> [140713 12:55]:
> > Contrary to what you seem to believe, this only really works if *both*
> > libraries have versioned symbols. Otherwise, you can end up with
> > libraries linked against the unversioned one using symbols from the
> > versioned one at run time when both are loaded in the same address
> > space.
> 
> Actually, "both having versioned symbols" is not enough.
> It is either "both must always have had versioned symbols" or
> "both must have versioned symbols now and every binary linked against
> either must have been built (or rebuilt) after the symbols got
> versioned".
> 
Bah. Thanks for the correction.

However, it seems that the current OpenSSL package _does_ have
fully-versioned symbols, at least if I understand "objdump -T"
correctly.

So the situation may not be as dire as this thread suggests.

-- 
-- Matthias Urlichs

Message #93 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Matthias Urlichs <matthias@urlichs.de>

Cc: debian-devel@lists.debian.org, 754513@bugs.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sun, 13 Jul 2014 22:48:37 +0900

On Sun, Jul 13, 2014 at 02:02:18PM +0200, Matthias Urlichs wrote:
> Hi,
> 
> Bernhard R. Link:
> > * Mike Hommey <mh@glandium.org> [140713 12:55]:
> > > Contrary to what you seem to believe, this only really works if *both*
> > > libraries have versioned symbols. Otherwise, you can end up with
> > > libraries linked against the unversioned one using symbols from the
> > > versioned one at run time when both are loaded in the same address
> > > space.
> > 
> > Actually, "both having versioned symbols" is not enough.
> > It is either "both must always have had versioned symbols" or
> > "both must have versioned symbols now and every binary linked against
> > either must have been built (or rebuilt) after the symbols got
> > versioned".
> > 
> Bah. Thanks for the correction.
> 
> However, it seems that the current OpenSSL package _does_ have
> fully-versioned symbols, at least if I understand "objdump -T"
> correctly.
> 
> So the situation may not be as dire as this thread suggests.

Well, it kind of is. Because those versioned symbols in openssl come
from a debian patch, afaict. So while debian may be fine (as long as all
build-rdeps have been rebuilt since openssl got those versioned
symbols), other distros aren't covered, as well as binaries not
compiled on debian.

Mike

Message #98 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Thomas Goirand <zigo@debian.org>

To: debian-devel@lists.debian.org, 754513@bugs.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sun, 13 Jul 2014 22:32:54 +0800

On 07/13/2014 09:48 PM, Mike Hommey wrote:
> On Sun, Jul 13, 2014 at 02:02:18PM +0200, Matthias Urlichs wrote:
>> Hi,
>>
>> Bernhard R. Link:
>>> * Mike Hommey <mh@glandium.org> [140713 12:55]:
>>>> Contrary to what you seem to believe, this only really works if *both*
>>>> libraries have versioned symbols. Otherwise, you can end up with
>>>> libraries linked against the unversioned one using symbols from the
>>>> versioned one at run time when both are loaded in the same address
>>>> space.
>>>
>>> Actually, "both having versioned symbols" is not enough.
>>> It is either "both must always have had versioned symbols" or
>>> "both must have versioned symbols now and every binary linked against
>>> either must have been built (or rebuilt) after the symbols got
>>> versioned".
>>>
>> Bah. Thanks for the correction.
>>
>> However, it seems that the current OpenSSL package _does_ have
>> fully-versioned symbols, at least if I understand "objdump -T"
>> correctly.
>>
>> So the situation may not be as dire as this thread suggests.
> 
> Well, it kind of is. Because those versioned symbols in openssl come
> from a debian patch, afaict. So while debian may be fine (as long as all
> build-rdeps have been rebuilt since openssl got those versioned
> symbols), other distros aren't covered, as well as binaries not
> compiled on debian.

Why should we care about other distros? Do they have an impact on us?

Thomas

Message #103 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Matthias Urlichs <matthias@urlichs.de>

Cc: debian-devel@lists.debian.org, 754513@bugs.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sun, 13 Jul 2014 14:16:29 -0300

On Sun, 13 Jul 2014, Matthias Urlichs wrote:
> for that (i.e. make sure that _everything_ in libressl is only exported 
> with properly versioned symbols), again IMHO the time and effort required

PLEASE PLEASE PLEASE PLEASE PLEASE take this to the portable libressl
upstream *and make it true* for the Linux targets.  Now.  Before people
start shipping for real non-versioned-symbols versions of libressl
everywhere and third party closed-source applications pick on that.

And please use a libressl-specific symbol version (LIBRESSLxy, for
example).

> that now; and while IANARTM (Release Team Member) transitioning the whole
> of Debian to libressl closer to the release would not be a good idea even
> if we decide it's (going to be) the better alternative.

Indeed.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message #108 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Matthias Urlichs <matthias@urlichs.de>

To: debian-devel@lists.debian.org, 754513@bugs.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sun, 13 Jul 2014 20:36:30 +0200

Hi,

Mike Hommey:
> Well, it kind of is. Because those versioned symbols in openssl come
> from a debian patch, afaict. So while debian may be fine (as long as all
> build-rdeps have been rebuilt since openssl got those versioned
> symbols), other distros aren't covered, as well as binaries not
> compiled on debian.
> 
I am, frankly, not at all concerned with binaries not compiled on Debian
at this point. Data point: Fedora uses a different symbol versioning
scheme for openssl, so openssl-linked binaries from there won't run on
Debian anyway.

It's far more imperative to educate upstream (in general, not just openssl
– but them in particular) about the fact that adding versioning to their
libraries is a Very Good Idea which will save them (and, more to the point,
anybody using their code) a whole lot of hassle – as well as potential
security holes – if/when their ABI changes.

-- 
-- Matthias Urlichs

Message #113 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Matthias Urlichs <matthias@urlichs.de>

Cc: debian-devel@lists.debian.org, 754513@bugs.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sun, 13 Jul 2014 17:07:39 -0300

On Sun, 13 Jul 2014, Matthias Urlichs wrote:
> I am, frankly, not at all concerned with binaries not compiled on Debian
> at this point. Data point: Fedora uses a different symbol versioning
> scheme for openssl, so openssl-linked binaries from there won't run on
> Debian anyway.
> 
> It's far more imperative to educate upstream (in general, not just openssl
> – but them in particular) about the fact that adding versioning to their
> libraries is a Very Good Idea which will save them (and, more to the point,
> anybody using their code) a whole lot of hassle – as well as potential
> security holes – if/when their ABI changes.

Meanwhile, we could try to get ever distro with a clue together, map the
versioned symbol diffs that already exist, and see if we can come up with a
plan to at least do downstream versioning in a compatible way.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message #118 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Steven Chamberlain <steven@pyro.eu.org>

To: 754513@bugs.debian.org

Cc: "debian-bsd@lists.debian.org" <debian-bsd@lists.debian.org>, debian-devel@lists.debian.org, 754513-submitter@bugs.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sun, 13 Jul 2014 21:43:04 +0100

On 12/07/14 02:09, Steven Chamberlain wrote:
> [...] these warnings would be treated as errors:
> 
>> > In file included from md5/md5_locl.h:98:0,
>> >                  from md5/md5_dgst.c:60:
>> > md5/md5_dgst.c: In function 'md5_block_data_order':
>> > ./md32_common.h:237:66: warning: right-hand operand of comma expression has no effect [-Wunused-value]
>> >  #  define HOST_c2l(c,l) ((l)=*((const unsigned int *)(c)), (c)+=4, l)
>> >                                                                   ^

A new upstream release LibreSSL 2.0.1 already addressed that:  basically
stop using -Werror in the portable library because many compilers have
warnings that OpenBSD's compiler does not, and I guess they did not
think the warnings legitimate or worth the effort of 'fixing' right now.

This new version brings in many small changes from the still-ongoing
cleanup.  ABI versions bumped to libcrypto 30.0.0 and libssl 27.0.0.
AFAICT only private_RC4_set_key was removed, and ssl_version_string
added to the respective libraries' exported symbols.

Am I right in thinking Debian would not bump its own SONAME if there
were unimportant ABI changes, like these seem to be?

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

Message #126 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Steven Chamberlain <steven@pyro.eu.org>

To: Toni Mueller <toni@debian.org>, 754513@bugs.debian.org, Kurt Roeckx <kurt@roeckx.be>

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Sun, 13 Jul 2014 23:16:03 +0100

On 12/07/14 12:53, Toni Mueller wrote:
> my intention is to package this stuff so one can have both openssl and
> libressl installed in parallel. libressl currently has libraries with
> these sonames:
> 
> libssl.so.26
> libcrypto.so.29

If the ABI is already different, there's no need for the library names
to exactly match what the Debian OpenSSL package has or what OpenBSD
uses?  Actually I think you should avoid it, to avoid any confusion.

Perhaps use libssl-openbsd.so.26, libcrypto-openbsd.so.30 just like we
did in src:freebsd-libs?  Or pick anything else that sounds better.

The "openssl" binary built by LibreSSL sources will also need to be
renamed, if they're to be co-installable.  To "libressl" I presume?
AFAIK the command-line apps have not changed significantly (except
bugfixes) so could be a drop-in replacement someday (much easier than
switching libraries).

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

Message #131 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be>

To: Matthias Urlichs <matthias@urlichs.de>

Cc: debian-devel@lists.debian.org, 754513@bugs.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Mon, 14 Jul 2014 00:43:03 +0200

On Sun, Jul 13, 2014 at 08:36:30PM +0200, Matthias Urlichs wrote:
> Hi,
> 
> Mike Hommey:
> > Well, it kind of is. Because those versioned symbols in openssl come
> > from a debian patch, afaict. So while debian may be fine (as long as all
> > build-rdeps have been rebuilt since openssl got those versioned
> > symbols), other distros aren't covered, as well as binaries not
> > compiled on debian.
> > 
> I am, frankly, not at all concerned with binaries not compiled on Debian
> at this point. Data point: Fedora uses a different symbol versioning
> scheme for openssl, so openssl-linked binaries from there won't run on
> Debian anyway.
> 
> It's far more imperative to educate upstream (in general, not just openssl
> - but them in particular) about the fact that adding versioning to their
> libraries is a Very Good Idea which will save them (and, more to the point,
> anybody using their code) a whole lot of hassle - as well as potential
> security holes - if/when their ABI changes.

I plan to try and get them to use symbol versioning, at least on
those platforms that support it.  This will probably be just like
the patch currently in Debian.  I don't plan to add multiple
versions of a symbol to try and keep the same soname since that
probably won't work on all platforms.

We also plan to reduce the risk of breaking the ABI.  Now a lot of
structs are public and we would like to make them private and
provide functions for those things that people want to access.

This will all probably take some time.

PS: If you use dlopen()/dlsym() to load functions, symbol
versioning doesn't help unless you use dlvsym() which is a
glibc extension.


Kurt

Message #136 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>

To: Toni Mueller <toni@debian.org>

Cc: 754513@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Mon, 14 Jul 2014 15:47:38 +0200

> I would like to make it co-installable with OpenSSL, but in general,
> this should be a drop-in replacement until APIs really diverge in a
> visible way. Yes, it would provide 'openssl', but I intend to place them
> into a different directory, so you might have to use LD_PATH to get
> them.

That reminds me of what we were trying to do with Xaw in the late 1990s.
Short story -- we tried and we failed.  I wish you better luck, but I fear
that you're setting on a course that will bring you a lot of pain.

In the late 1990s, the only widget set that was free, usable and vendor-
neutral was Xaw , which was fairly functional but whose appearance was
already somewhat dated.

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

There were two "drop in" libraries that were meant to provide binary
compatibility with Xaw but with a more pleasant appearance, called Xaw3d
and (I think) NextAw.  Branden Robinson's plan was to allow the user to
select the appearance by setting LD_LIBRARY_PATH to point at one or the
other of the Xaw libraries.

It worked reasonably well as long as the user was just using the sample
applications provided with X.  However, real applications would sometimes
subclass widgets, which would cause them to crash unpredictably.  Whenever
we got a crash report against an Xaw application, the first question was
"does unsetting LD_LIBRARY_PATH fix it?".

After XFree86 changed the Xaw ABI with Xaw6, Branden finally gave up, and
agreed to make Xaw3d an independent library that applications could link
against rather than a drop-in replacement.  Then Xaw got obsoleted by Gtk+,
and the point became moot.

History does not necessarily repeat itself, of course.  Thanks for
listening to an old man's story.

-- Juliusz

Message #141 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Kurt Roeckx <kurt@roeckx.be>

Cc: Matthias Urlichs <matthias@urlichs.de>, debian-devel@lists.debian.org, 754513@bugs.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Mon, 14 Jul 2014 14:09:55 -0300

On Mon, 14 Jul 2014, Kurt Roeckx wrote:
> I plan to try and get them to use symbol versioning, at least on
> those platforms that support it.  This will probably be just like

Thank you.

> the patch currently in Debian.  I don't plan to add multiple
> versions of a symbol to try and keep the same soname since that
> probably won't work on all platforms.

We want _all_ visible libressl symbols versioned, but that's for protective
namespacing, and not for backwards binary compatibility.  That's why it
should be a libressl-specific symbol version, since full guaranteed
*internal* ABI compatibility with openssl is not really happening.

We've been through this hell with libpng, libsasl, and openssl itself...
I still think we should forbid any libraries with unversioned symbols in
Debian, unless they're guaranteed to never be linked by other libraries
(including nss modules and the like).  Solaris got this idea right nearly
two decades ago.

Use of symbol versioning for providing several versions of the same symbol
for backwards binary compatibility (like it is done by glibc) has its own
problems and limitations.  Those were rehearsed ad nauseam some years ago,
and that's _not_ what we're talking about here, anyway.

> We also plan to reduce the risk of breaking the ABI.  Now a lot of
> structs are public and we would like to make them private and
> provide functions for those things that people want to access.

Seems sensible.

> This will all probably take some time.

As long as you don't mean to wait to deploy symbol versioning.  It becomes
*really* painful after a while.  Changes to symbol versioning requires
everyone to recompile everything that uses the library.

It is bad enough when you go from unversioned to versioned symbols (the
binary will still run but you get a warning about it every time), but it is
hell when you switch[1] symbol versioning decoupled from a major soname
bump, because everything that is not recompiled with the new symbols will
fail to runtime link, requiring coordinated transitions/flag-days to avoid
this.

[1] as in change the namespace, and _not_ as in provide a new version of
symbols while also providing the older versions of the symbol around.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message #146 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be>

To: Henrique de Moraes Holschuh <hmh@debian.org>

Cc: Matthias Urlichs <matthias@urlichs.de>, debian-devel@lists.debian.org, 754513@bugs.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Mon, 14 Jul 2014 19:27:35 +0200

On Mon, Jul 14, 2014 at 02:09:55PM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 14 Jul 2014, Kurt Roeckx wrote:
> > I plan to try and get them to use symbol versioning, at least on
> > those platforms that support it.  This will probably be just like
> 
> Thank you.
> 
> > the patch currently in Debian.  I don't plan to add multiple
> > versions of a symbol to try and keep the same soname since that
> > probably won't work on all platforms.
> 
> We want _all_ visible libressl symbols versioned, but that's for protective
> namespacing, and not for backwards binary compatibility.  That's why it
> should be a libressl-specific symbol version, since full guaranteed
> *internal* ABI compatibility with openssl is not really happening.

If it wasn't clear, I was talking about openssl not libressl.

But libressl really should use symbol versions too.  The patch in
Debian's openssl should be a good starting point, but you need to
rename the symbol version to something else.  If you change the
soname you also want to change the symbol versions, so keep that
in mind when picking the version you're going to use.


Kurt

Message #151 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Kurt Roeckx <kurt@roeckx.be>

Cc: Matthias Urlichs <matthias@urlichs.de>, debian-devel@lists.debian.org, 754513@bugs.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Mon, 14 Jul 2014 14:36:08 -0300

On Mon, 14 Jul 2014, Kurt Roeckx wrote:
> On Mon, Jul 14, 2014 at 02:09:55PM -0300, Henrique de Moraes Holschuh wrote:
> > On Mon, 14 Jul 2014, Kurt Roeckx wrote:
> > > I plan to try and get them to use symbol versioning, at least on
> > > those platforms that support it.  This will probably be just like
> > 
> > Thank you.
> > 
> > > the patch currently in Debian.  I don't plan to add multiple
> > > versions of a symbol to try and keep the same soname since that
> > > probably won't work on all platforms.
> > 
> > We want _all_ visible libressl symbols versioned, but that's for protective
> > namespacing, and not for backwards binary compatibility.  That's why it
> > should be a libressl-specific symbol version, since full guaranteed
> > *internal* ABI compatibility with openssl is not really happening.
> 
> If it wasn't clear, I was talking about openssl not libressl.

I see.

> But libressl really should use symbol versions too.  The patch in
> Debian's openssl should be a good starting point, but you need to
> rename the symbol version to something else.  If you change the
> soname you also want to change the symbol versions, so keep that
> in mind when picking the version you're going to use.

i.e. get the soname into the symbol version string.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message #156 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Toni Mueller <toni@debian.org>

To: Thomas Goirand <zigo@debian.org>

Cc: 754513@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Mon, 14 Jul 2014 20:48:32 +0200

Hi Thomas,

On Sun, Jul 13, 2014 at 11:52:24AM +0800, Thomas Goirand wrote:
> On 07/12/2014 08:46 PM, Toni Mueller wrote:
> > As libressl is currently under
> > heavy development, it is imho not to be expected to have that stable ABI
> > you are asking for.
> 
> Well, I don't agree with this view. If LibreSSL pretends to be a
> replacement for OpenSSL, then they should care about being ABI
> compatible,

but they are only partially compatible already. The one thing that
appears to stick out is that libressl has *no* support for egd, and on
purpose (ie, it will not come back). And the other is arc4random().

> so we can easily switch from one implementation to the
> other. Just like for MariaDB / MySQL in fact (not sure if these are
> still ABI compatible though). If that's not the case, then it looses a
> lot of its purpose. As Kurt wrote, GNUTLS becomes a better alternative then.

If your application does not use things which are deemed deprecated,
then it should be quite compatible, but by ripping out tons of old
stuff, they of course also break something, at some point. The whole API
becomes smaller simply because of that (I don't think this will be
offset by the added features in other areas, like adding better cipher
suites).

As for GnuTLS, all I read so far is that it requires a *lot* of work to
make a single application which has been developed together with
OpenSSL, compatible with GnuTLS, because apparently almost everything
differs to the point that it is unfeasible or impossible to have a
compatibility layer. That turns smaller adjustments in applications into
developing entirely different interfaces for each application, while
GnuTLS itself still lacks a lot of features. At the face of it, that
sounds like it is at least an order of magnitude more work, but likely
even much more than that. And add to that that GnuTLS apparently works
incorrectly almost half of the time (which translates to a significant
security *downgrade* in my eyes), there is a huge amount of work set for
those who would really try to fix it (ignoring the row between the
upstream author and the FSF aside for the moment).

> > OTOH, one guy already switched his entire Linux
> > system over, so far with no visible adverse effects.
> 
> And then? This gives no clue if he had to rebuild everything that
> build-depended on OpenSSL...

That I don't know, but I have posed this question to the guy who made
that statement. I'll keep you posted.

> On 07/13/2014 01:15 AM, Russ Allbery wrote:
> > If you start using both for different packages, then you end up with
> > shared libraries conflicting over which libssl they want to use, and
> > then bad things start happening.
> 
> Exactly! I fully agree with you on this.

I do not think that accidentically using one library when one wanted to
use the other will be an issue. FWIW, I've been told that a separate
"libressl.so" is in the making, and if so, binary incompatibility can be
taken for granted.

> This reminds me issues I had with mod-log-sql linked to MySQL and php
> as well, and when they were built against different versions... BOOM!
> I certainly do *not* want this kind of things to happen in Debian.
> Therefore, I'd very much prefer if we used OpenSSL *or* LibreSSL, but
> not have the choice between the 2, otherwise, that's a recipe for
> disaster.

Ummm... what was "BOOM" exactly, please? Because within a release,
OpenSSL ("letter") versions should all be compatible with each other.

> Please don't upload LibreSSL to Sid *ever*, unless we collectively
> decide that we are switching away from OpenSSL (and for which a
> discussion would have to start).

Well... as I said, I'm first and foremost planning to get it into
experimental, and then we can see what it really is, fix the packaging
etc.pp., and evaluate the package along the way. And while I hold the
OpenBSD developers in very high esteem, I am still a bit wary that the
package might be not as secure as we wish it to be, and therefore guess
that we want to evaluate the package thoroughly for some time before the
discussion about switching over can even start in a reasonable manner.

Having said that, I value all of your input, but feel not halfway as
much trigger happy as some of you seem to think I am.


Kind regards,
--Toni++

Message #161 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Toni Mueller <toni@debian.org>

To: Jeroen Dekkers <jeroen@dekkers.ch>

Cc: 754513@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Mon, 14 Jul 2014 22:08:01 +0200

Hi Jeroen,

On Sun, Jul 13, 2014 at 12:22:49PM +0200, Jeroen Dekkers wrote:
> At Sat, 12 Jul 2014 14:46:45 +0200, Toni Mueller wrote:
> > Ok, but for whatever reason, they have an imho not as shiny track
> > record, as has OpenBSD. Which is no wonder, given all the revelations we
> > have had recently, but hey, sometimes one has to make a decision.
> 
> OpenSSL was part of OpenBSD before they created the LibreSSL fork, so
> how isn't OpenSSL part of the OpenBSD track record?

it is in the way that they include it, and it also contributed a
significant amount of all patches that were required over the years, but
the typical way OpenBSD operates - from my perspective - is, they
include something (eg. Sendmail), and once they get fed up with it for
whatever reason, unless they find something acceptable out there (eg.
nginx instead of Apache, or nsd(?)+unbound instead of BIND), they start
to roll their own. A few releases later, the old stuff is being demoted
or removed entirely (eg. for RAIDframe -> softraid, the switchover
period where you could choose was more than four years, afair). Such
changes do happen in a disruptive manner, as there is usually nothing
that aids you in converting your setup from the old to the new software.

> It depends on how you look at it. If you see the OpenSSL API as
> something that isn't really well designed then other libraries not
> copying the API is actually a good thing.

Yes and no, but if it is more than ten times the amount of work, it is
likely never getting done, for the simple reason that everyone is
lacking resources.

> You forget one of the big problems with OpenSSL that LibreSSL doesn't
> fix: the license.

Granted. Due to the amount of inherited code, it can't. We'll see how
things evolve as the amount of inherited code will dwindle.

> It actually makes the mess even bigger, given that
> some of the GPL exceptions only talk about "the OpenSSL library" and
> don't exempt OpenSSL-derived code. So even if LibreSSL is a drop-in
> for OpenSSL we can't replace OpenSSL with LibreSSL for those projects.

Yes. Thanks for pointing this out.

> You also forget to list two other TLS libraries:
> 
> * NSS, in my opinion the biggest downside of NSS is that it includes
>   NSPR. This both increases the code size a lot and makes the API less
>   nice if I remember correctly.

Hmmm... yes. I was under the impression that not very many people were
using it, but looking at my system, NSS + NSPR ~ 3,5MB, while
libssl1.0.0 comes in at ~3MB. Add ~1MB for sqlite3 and zlib1g in the
case of NSS...

> * PolarSSL, which I really like from a technical point of
>   view. Featurewise it is pretty complete (the only major feature it
>   doesn't implement is DTLS AFAICS), while being one tenth the size of
>   OpenSSL / GnuTLS:
>   https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Code_size_and_dependencies
>   PolarSSL is also used by OpenVPN-NL, the hardened OpenVPN version
>   that is used by the Dutch government.
>   The downsides are that it looks like it doesn't have a stable API
>   and contributing needs copyright assignment because it is
>   dual-licensed.

It still gets 5 out of 16 answers wrong, as per the comparison sheet
included here:

https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf



Kind regards,
--Toni++

Message #166 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Steven Chamberlain <steven@pyro.eu.org>

To: Toni Mueller <toni@debian.org>, 754513@bugs.debian.org, Jeroen Dekkers <jeroen@dekkers.ch>

Cc: debian-devel@lists.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Mon, 14 Jul 2014 21:27:53 +0100

On 14/07/14 21:08, Toni Mueller wrote:
>> > You forget one of the big problems with OpenSSL that LibreSSL doesn't
>> > fix: the license.
> Granted. Due to the amount of inherited code, it can't. We'll see how
> things evolve as the amount of inherited code will dwindle.

So, merely as a result of the licensing, we could have a fascinating
situation whereby:
* BSD-licensed software contemplates switching from OpenSSL to LibreSSL
* GNU-licensed software keeps using OpenSSL with license exception, or
maybe someday switches to GnuTLS

So, this reduces the amount of software that could potentially switch
from OpenSSL from LibreSSL.  And since BSD and GNU software are unable
to link against each other, it reduces the likelihood that something
will indirectly link against OpenSSL and LibreSSL at the same time (the
situation Russ Allbery described).

So actually I think this simplifies things.

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

Message #171 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Paul Tagliamonte <paultag@debian.org>

To: Toni Mueller <support@oeko.net>, 754513@bugs.debian.org

Cc: debian-devel@lists.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Tue, 15 Jul 2014 22:06:47 -0400

[Message part 1 (text/plain, inline)]

On Sat, Jul 12, 2014 at 12:06:27AM +0200, Toni Mueller wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Toni Mueller <toni@debian.org>
> 
> * Package name    : libressl
>   Version         : 2.0.0
>   Upstream Author : The OpenBSD project, the OpenSSL project et al.
> * URL             : http://www.libressl.org/
> * License         : BSD, OpenSSL, SSLeay, Public Domain.
>   Programming Lang: C
>   Description     : SSL library, forked from OpenSSL
> 
> 
> LibreSSL strives to maintain API compatibility with OpenSSL, but
> do away with all the cruft.
> 
> After a long series of OpenSSL problems, recently highlighted by
> the infamous Heartbleed bug, a group inside OpenBSD decided to
> fork OpenSSL and adapt the code to modern coding standards.
> Along the way, a lot of compatibility with older architectures
> and toolchains was discarded.

I didn't see this yet in the thread, so:

https://www.agwa.name/blog/post/libressls_prng_is_unsafe_on_linux
http://arstechnica.com/security/2014/07/only-a-few-days-old-openssl-fork-libressl-is-declared-unsafe-for-linux/
http://lwn.net/Articles/605509/

(Pick your news source)

Flame-ingly yours,
  Paul

-- 
 .''`.  Paul Tagliamonte <paultag@debian.org>  |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `-     http://people.debian.org/~paultag/conduct-statement.txt

[signature.asc (application/pgp-signature, inline)]

Message #176 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Steven Chamberlain <steven@pyro.eu.org>

To: Paul Tagliamonte <paultag@debian.org>, 754513@bugs.debian.org, Toni Mueller <support@oeko.net>

Cc: debian-devel@lists.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Wed, 16 Jul 2014 19:54:38 +0100

[Message part 1 (text/plain, inline)]

On 16/07/14 03:06, Paul Tagliamonte wrote:
> I didn't see this yet in the thread, so:
> https://www.agwa.name/blog/post/libressls_prng_is_unsafe_on_linux

What's most interesting is that someone spent such effort to look for
this;  that there are so many eyes now on both the original OpenSSL and
the new LibreSSL code.  Both projects ought to benefit from this.

This was a real, but totally contrived issue with many preconditions:

* initial 'grandparent' process initialises LibreSSL's PRNG, then forks
* first-forked process does not use the PRNG yet, but forks again
* grandparent uses the PRNG for things and then exits, freeing up the
pid to be re-used
* second-forked 'grandchild' process might coincidentally get the same
pid as its grandparent
* grandchild uses the PRNG for things;  LibreSSL would not realise it
has forked if the pid is the same, so does not reseed - PRNG output
would be repeated from what the grandparent got before it exited -
possibly having security impact


The other major concern was about scary entropy-gathering code,
implemented in LibreSSL Portable for Linux as a last resort for when
/dev/urandom can't be read.  I agree that it's too risky, or:  too
difficult to prove safe and robust in any conceivable situation.
Debian's major OpenSSL bug was able to happen undetected for a while out
of similar circumstances.

A compile-time ifdef already allows to disable this fallback code and
raise SIGKILL instead, crashing the calling process.  As part of the
LibreSSL port to GNU/kFreeBSD and Hurd I would actually have asked that
we do this anyway in Debian, at least for those platforms.

It seems extreme, but the point is that something must be wrong on the
system if we get to the fallback code - /dev/urandom missing from a
chroot, or fd's exhausted, and the kernel not having a reliable sysctl
interface like OpenBSD's to get random bytes in the first place.

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

[signature.asc (application/pgp-signature, attachment)]

Message #181 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Steven Chamberlain <steven@pyro.eu.org>

Cc: 754513@bugs.debian.org, Toni Mueller <support@oeko.net>, debian-devel@lists.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Wed, 16 Jul 2014 22:13:41 +0200

Hi!

On Wed, 2014-07-16 at 19:54:38 +0100, Steven Chamberlain wrote:
> The other major concern was about scary entropy-gathering code,
> implemented in LibreSSL Portable for Linux as a last resort for when
> /dev/urandom can't be read.  I agree that it's too risky, or:  too
> difficult to prove safe and robust in any conceivable situation.
> Debian's major OpenSSL bug was able to happen undetected for a while out
> of similar circumstances.
> 
> A compile-time ifdef already allows to disable this fallback code and
> raise SIGKILL instead, crashing the calling process.  As part of the
> LibreSSL port to GNU/kFreeBSD and Hurd I would actually have asked that
> we do this anyway in Debian, at least for those platforms.

kFreeBSD does have a supported sysctl for this: CTL_KERN KERN_ARND.
(As does NetBSD which has two, KERN_URND and KERN_ARND.)

Thanks,
Guillem

Message #186 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Steven Chamberlain <steven@pyro.eu.org>

To: 754513@bugs.debian.org, Toni Mueller <support@oeko.net>, debian-devel@lists.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Wed, 16 Jul 2014 21:57:49 +0100

(This may seem a little off-topic for the ITP but please bear with me...)

On 16/07/14 21:13, Guillem Jover wrote:
> kFreeBSD does have a supported sysctl for this: CTL_KERN KERN_ARND.
> (As does NetBSD which has two, KERN_URND and KERN_ARND.)

Actually yes, we would certainly want to use that.  But is there any
conceivable way it could fail?  (sysctl calls can return an error code).
 What could we do then?

We'd need to figure this out if we want the prospective libressl package
to build on GNU/kFreeBSD on Hurd.  Currently it won't build, because it
needs either a kernel-specific getentropy implementation, or arc4random.

libbsd's arc4random.c, I'm guessing was based on older OpenSSH Portable
sources.  If reading /dev/urandom fails, it uses only gettimeofday,
getpid, and uninitialised bytes from the stack (as a seed to the PRNG).

LibreSSL Portable on Linux has the new, scary fallback mechanism
instead, more comprehensive, but I honestly don't like that approach.
It's too difficult to estimate how much entropy it could really gather,
or potential failure cases.  And we wouldn't even know when the fallback
was being used.

Native OpenBSD would actually raise SIGKILL if their sysctl fails.
(Their cvsweb is down - quoting inline from arc4random.c instead) :

> _rs_stir(void)
> 	[...]
> 	if (getentropy(rnd, sizeof rnd) == -1)
> 		raise(SIGKILL);

libevent's arc4stir is different again;  it's defined to return an int,
with -1 indicating a failure of all attempts to seed:
* from /dev/urandom
* from /proc/sys/kernel/random/uuid
* using a kernel-specific sysctl

These arc4random implementations also differ in which stream cipher they
use also (RC4 originally, ChaCha20 in newer OpenBSD code).

As a result of all this mess, I think we should be looking to converge
on a single arc4random implementation, in a place such as libbsd, but
make sure it is up to the task first.

If arc4random is available and LDFLAGS include -lbsd, LibreSSL Portable
will actually use it instead of the bundled implementation.  I'm
guessing OpenSSH Portable would do this too (I can see it being tested
for by ./configure in the buildd log).

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

Message #191 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Steven Chamberlain <steven@pyro.eu.org>

To: 754513@bugs.debian.org, Toni Mueller <support@oeko.net>, debian-devel@lists.debian.org

Subject: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

Date: Wed, 16 Jul 2014 22:18:42 +0100

Oh, and note that OpenSSH Portable uses RAND_bytes from libssl to seed
its arc4random implementation.

So AFAICT if you were to link OpenSSH Portable against LibreSSL
Portable, it would get really crazy:

/dev/urandom or sysctl or scary fallback ->
LibreSSL Portable getentropy ->
LibreSSL Portable arc4random.c (ChaCha-20) ->
LibreSSL RAND_bytes ->
OpenSSH Portable arc4random.c (ChaCha-20) ->
OpenSSH

with the stream cipher, seeding and stirring all happening twice.

So I really like the idea of both getting an arc4random implementation
from one place, such as libbsd.

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

Message #196 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Brent Cook <busterb@gmail.com>

To: 754513@bugs.debian.org

Subject: Questions from upstream

Date: Mon, 21 Jul 2014 07:10:54 -0500

[Message part 1 (text/plain, inline)]

Hi, I noticed the ITP for libressl and wanted to ask a few questions:

1. I'm setting up pbuilder to do some automated testing, could I have
access to the prototype debian package control files for libressl?

2. Do you have a more automated way of generating that symbol versioning
script, and are you planning on pushing that upstream? Currently, we're
bumping the major on ABI changes (note we're at 30 and 27), so I'm not
entirely following the need to version individual symbols. Some of
libressl's non-opaque structs have also changed in size or layout compared
to openssl.

3. I'm looking at some of the warnings on gcc 4.9 mentioned above. They
look like dead code that's simply not caught by the other compilers we
tested, we will review fixing that.

Also, please do not replace arc4random in libressl. We'll have to figure
out what to do about the circular dependency with openssh, but replacing
with the version from libbsd is really not the way to go at the moment.
Please at least ping tech@openbsd.org (or you can report on the github
mirror), if you're making any changes to the way the library handles OS
compatibility.

[Message part 2 (text/html, inline)]

Message #201 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Steven Chamberlain <steven@pyro.eu.org>

To: Brent Cook <busterb@gmail.com>, 754513@bugs.debian.org

Subject: Re: Bug#754513: Questions from upstream

Date: Mon, 21 Jul 2014 13:31:45 +0100

Hi Brent,

Thank you very much for your input here.

On 21/07/14 13:10, Brent Cook wrote:
> Also, please do not replace arc4random in libressl. We'll have to figure
> out what to do about the circular dependency with openssh

OK, let's see what the OpenSSH Portable team comes up with...

Having embedded copies of arc4random.c in different packages though
(libressl, openssh, libevent, libbsd) is not great.  It would be nice to
someday package it into a re-usable library for all of Debian to use,
and for ensuring it always stays up-to-date with upstream.

(The one in LibreSSL Portable is currently the most up-to-date;  I
realise other/older versions of it are unsafe for some use cases).

> replacing
> with the version from libbsd is really not the way to go at the moment

Agreed, there are serious problems with the arc4random in libbsd at the
moment (I'm looking at our options to fix this).  But if we could
someday split out arc4random, then libbsd would seem like a good place
to put it.

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

Message #206 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Brent Cook <busterb@gmail.com>

To: Steven Chamberlain <steven@pyro.eu.org>

Cc: 754513@bugs.debian.org

Subject: Re: Bug#754513: Questions from upstream

Date: Mon, 21 Jul 2014 11:58:47 -0500

On Jul 21, 2014, at 7:31 AM, Steven Chamberlain <steven@pyro.eu.org> wrote:

> Hi Brent,
> 
> Thank you very much for your input here.
> 
> On 21/07/14 13:10, Brent Cook wrote:
>> Also, please do not replace arc4random in libressl. We'll have to figure
>> out what to do about the circular dependency with openssh
> 
> OK, let's see what the OpenSSH Portable team comes up with...
> 
> Having embedded copies of arc4random.c in different packages though
> (libressl, openssh, libevent, libbsd) is not great.  It would be nice to
> someday package it into a re-usable library for all of Debian to use,
> and for ensuring it always stays up-to-date with upstream.
> 
> (The one in LibreSSL Portable is currently the most up-to-date;  I
> realise other/older versions of it are unsafe for some use cases).
> 
>> replacing
>> with the version from libbsd is really not the way to go at the moment
> 
> Agreed, there are serious problems with the arc4random in libbsd at the
> moment (I'm looking at our options to fix this).  But if we could
> someday split out arc4random, then libbsd would seem like a good place
> to put it.

OK. Someone, whom I think is a libbsd maintainer, expressed interest in updating libbsd as well:

https://github.com/busterb/libressl/issues/5

In the short term, we are doing some refactoring to make arc4random even more portable in LibreSSL, and will be adding support for the new Linux getrandom syscall if/when it lands as well.

I wonder if libc integration would be the best integration path, since not everything that integrates arc4random/arc4random_buf uses an external library to provide that functionality. Take libevent2, which also embeds its own implementation if the system does not have it.

If there was a secure arc4random implementation that all apps could use on Linux without any special libraries, that would kill a few birds with one stone.

> Regards,
> -- 
> Steven Chamberlain
> steven@pyro.eu.org

Message #217 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: Toni Mueller <support@oeko.net>, 754513@bugs.debian.org

Cc: debian-devel@lists.debian.org, openssl@packages.debian.org

Subject: Re: Bug#754513: RFP: libressl -- SSL library, forked from OpenSSL

Date: Mon, 16 Oct 2017 17:29:09 +0100

On Sat, Jul 12, 2014 at 12:06:27AM +0200, Toni Mueller wrote:
> * Package name    : libressl
>   Version         : 2.0.0
>   Upstream Author : The OpenBSD project, the OpenSSL project et al.
> * URL             : http://www.libressl.org/
> * License         : BSD, OpenSSL, SSLeay, Public Domain.
>   Programming Lang: C
>   Description     : SSL library, forked from OpenSSL
> 
> 
> LibreSSL strives to maintain API compatibility with OpenSSL, but
> do away with all the cruft.
> 
> After a long series of OpenSSL problems, recently highlighted by
> the infamous Heartbleed bug, a group inside OpenBSD decided to
> fork OpenSSL and adapt the code to modern coding standards.
> Along the way, a lot of compatibility with older architectures
> and toolchains was discarded.

[I won't quote everything, but people replying to this should probably
read the bug log in the BTS first.]

This was some years ago, and in the meantime Toni said it was too much
for them at the moment and retitled the bug to RFP.


In the meantime, the situation with OpenSSH is becoming critical.
OpenSSL has moved to a new API in version 1.1 which does a much better
job of making internal data structures opaque, but requires significant
changes to application code.  (LibreSSL has not yet adopted this API.)
OpenSSH needs to continue working on OSes that only have OpenSSL 1.0,
not to mention with LibreSSL.

While there does exist a skeletal compatibility layer linked from the
upstream wiki [1], the OpenSSL developers explicitly don't want to
maintain this properly [2], and the OpenSSH developers say that it is
"unversioned, incomplete, barely documented, and seems to be
unmaintained" [3].  Kurt Roeckx proposed a patch to add a compatibility
shim [4], and a number of other projects have done something similar,
but the OpenSSH developers have explicitly said that they do not want to
take that approach [5].

It's not currently clear to me whether anyone has explicitly talked with
the OpenSSL developers about this problem from the point of view of the
OpenSSH developers, rather than just as users trying to get OpenSSH to
compile against the new version.

Furthermore, the OpenSSL maintainers in Debian now want to drop their
1.0 compatibility packages, which the Debian OpenSSH packages rely on.
I can't exactly fault them for wanting to reduce their maintenance
burden, but it is going to put me in a very difficult position soon; and
I assume that they don't actually want to break OpenSSH either.

The OpenSSH developers are starting to talk about bundling LibreSSL to
avoid this problem [3], noting that OpenBSD and Apple already link
OpenSSH against LibreSSL.  (Note that OpenSSH only uses libcrypto, not
libssl, so while this has all the usual problems of bundling, the
exposure isn't quite as horrific as it might first seem.)


At the moment I can see the following somewhat realistic paths forward:

 * Convince people to keep OpenSSL 1.0 on life support in Debian for a
   while longer.  This probably only postpones the problem, but it might
   be helpful anyway.  One possibility which might help would be to
   split libcrypto into separate runtime and development packages, and
   then drop just libssl 1.0; this would allow keeping around packages
   which only use libcrypto, while still being able to make progress on
   packages that use libssl, which AIUI is the more pressing problem.

 * Convince people to package LibreSSL for Debian in parallel.  As noted
   in the log of this bug, there are some problems to solve there, both
   technical and political, but they don't seem insurmountable.  Of
   course it would mean another SSL implementation in the archive, which
   I realise is probably not the favourite outcome for the security
   team.

 * Accept an upstream bundling of LibreSSL (still hypothetical, but
   plausible).  I'm sure this would also not be the security team's
   favourite outcome, although presumably only a subset of LibreSSL CVEs
   would apply to OpenSSH, and it wouldn't be making it available as a
   general-purpose library.

 * Take Kurt's patch to switch to the 1.1 API.  Fedora have done this.
   I'm extremely reluctant to do this because it's a >3000-line patch
   touching most of OpenSSH's cryptographic internals, which is bound to
   produce lots of difficult conflicts on pretty much every new upstream
   release.  We carry another patch of a similar size (GSS-API key
   exchange), but at least the bulk of that is a matter of plugging new
   mechanisms into relatively general interfaces, and I more or less
   understand how it all works; even so, that patch alone has delayed my
   uploads of some new upstream releases by weeks or more.  The 1.1 API
   patch would probably be more than I can cope with maintaining for the
   long term.

I have heard suggested or thought of some other plans that I don't think
are viable and I will not pursue:

 * Switch to PKIX-SSH, an OpenSSH fork with 1.1 support.  This fork adds
   new features, making it a one-way transition.  With all due respect,
   as far as I can tell it's a one-person fork with very limited uptake
   compared to OpenSSH, and I don't think it would be wise to switch
   Debian over to it.  (If somebody wants to package it separately for
   the extra features, that's their affair, but it wouldn't solve the
   problem at hand.)

 * Start a team to maintain an OpenSSL 1.1 compatibility layer myself.
   Ingo Schwarze persuaded me on openssl-unix-dev that this was a bad
   idea.  I would be happy if the OpenSSL developers carried this
   forward as a proper project rather than just as an unversioned
   tarball dump, but I'm not in a position to tell them what to do.

 * Configure OpenSSH using --without-openssl, and use only its internal
   crypto functions.  I mention this mainly for completeness, but if you
   do this you only get a very limited feature set (e.g. only ED25519
   keys); it's a long way off being viable.


Out of all of these, I think the option that I think has the fewest
downsides overall is to convince people to package LibreSSL, but I'm not
myself in a position to contribute to that effort.

Does anyone have thoughts or other options, or want to help?


[1] https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes
[2] https://mta.openssl.org/pipermail/openssl-users/2017-April/005540.html
[3] https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036346.html
[4] https://github.com/openssh/openssh-portable/pull/48
[5] Sorry, I don't have a link for this right now; if needed I can trawl
    back through openssh-unix-dev history for it.

-- 
Colin Watson                                       [cjwatson@debian.org]

Message #222 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be>

To: Toni Mueller <support@oeko.net>, 754513@bugs.debian.org, debian-devel@lists.debian.org, openssl@packages.debian.org

Subject: Re: [Pkg-openssl-devel] Bug#754513: RFP: libressl -- SSL library, forked from OpenSSL

Date: Mon, 16 Oct 2017 18:57:33 +0200

On Mon, Oct 16, 2017 at 05:29:09PM +0100, Colin Watson wrote:
> 
> While there does exist a skeletal compatibility layer linked from the
> upstream wiki [1], the OpenSSL developers explicitly don't want to
> maintain this properly [2], and the OpenSSH developers say that it is
> "unversioned, incomplete, barely documented, and seems to be
> unmaintained" [3].  Kurt Roeckx proposed a patch to add a compatibility
> shim [4], and a number of other projects have done something similar,
> but the OpenSSH developers have explicitly said that they do not want to
> take that approach [5].

My understanding is they would only be happy if we turn that file
into a library they can link to. It would require that all the
functions get renamed, which should be easy to do in a header
file.

> It's not currently clear to me whether anyone has explicitly talked with
> the OpenSSL developers about this problem from the point of view of the
> OpenSSH developers, rather than just as users trying to get OpenSSH to
> compile against the new version.

The question we got asked is to add that compatibility in the
openssl 1.0 package, which really doesn't solve anything.



Kurt

Message #227 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: 754513@bugs.debian.org, debian-devel@lists.debian.org, openssl@packages.debian.org

Subject: Re: Bug#754513: RFP: libressl -- SSL library, forked from OpenSSL

Date: Mon, 16 Oct 2017 13:07:43 -0400

On Mon, Oct 16, 2017 at 05:29:09PM +0100, Colin Watson wrote:
>Out of all of these, I think the option that I think has the fewest
>downsides overall is to convince people to package LibreSSL, but I'm not
>myself in a position to contribute to that effort.
>
>Does anyone have thoughts or other options, or want to help?

My understanding is that the libressl project does not support a release 
for the length of a debian release cycle, and does not commit to API 
stability for debian-cycle periods. (The openbsd model historically is 
to break ABI and even API between releases, in order to minimize 
compatability code, which works with their rebuild-the-world release 
model.) Is there any sign that if debian packages libressl in order to 
use openssh, debian would not end up being the de facto maintainers of 
an unsupported years-old libressl release by the end of a debian 
stable release cycle (not to mention debian LTS)? I think that in 
practical terms that would leave us worse off than settling on a 
compatability layer that's shared with other distributions.

Mike Stone

Message #232 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>

To: Toni Mueller <support@oeko.net>, 754513@bugs.debian.org, debian-devel@lists.debian.org, openssl@packages.debian.org

Subject: Re: Bug#754513: RFP: libressl -- SSL library, forked from OpenSSL

Date: Mon, 16 Oct 2017 22:00:50 +0200

On 2017-10-16 17:29:09 [+0100], Colin Watson wrote:
> [I won't quote everything, but people replying to this should probably
> read the bug log in the BTS first.]

It was a lot to read and "they" stumbled over details.

> While there does exist a skeletal compatibility layer linked from the
> upstream wiki [1], the OpenSSL developers explicitly don't want to
> maintain this properly [2], and the OpenSSH developers say that it is
> "unversioned, incomplete, barely documented, and seems to be
> unmaintained" [3].  Kurt Roeckx proposed a patch to add a compatibility
> shim [4], and a number of other projects have done something similar,
> but the OpenSSH developers have explicitly said that they do not want to
> take that approach [5].
It has never been explained what it is that upstream wants. I get the
impression, that they want a compat/shim layer and things have to work
  https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-November/035456.html
  https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-November/035497.html
I didn't even figure out if they want to alter their code or not.

> It's not currently clear to me whether anyone has explicitly talked with
> the OpenSSL developers about this problem from the point of view of the
> OpenSSH developers, rather than just as users trying to get OpenSSH to
> compile against the new version.

Kurt is aware of the situation, he is part of upstream. It might be that
OpenSSH is playing hard to get.

> At the moment I can see the following somewhat realistic paths forward:
> 
>  * Accept an upstream bundling of LibreSSL (still hypothetical, but
>    plausible).  I'm sure this would also not be the security team's
>    favourite outcome, although presumably only a subset of LibreSSL CVEs
>    would apply to OpenSSH, and it wouldn't be making it available as a
>    general-purpose library.

4.13. Convenience copies of code

> I have heard suggested or thought of some other plans that I don't think
> are viable and I will not pursue:
> 
>  * Switch to PKIX-SSH, an OpenSSH fork with 1.1 support.  This fork adds
>    new features, making it a one-way transition.  With all due respect,
>    as far as I can tell it's a one-person fork with very limited uptake
>    compared to OpenSSH, and I don't think it would be wise to switch
>    Debian over to it.


I am somehow in favour of that as I expressed it in #828475. It looks
like a one man show, yes, but it looks maintained for more than a
decade. Maybe we could check with Fedora/Red Hat what they think about
switching to that fork. However a larger user basis does not solve the
problem what should be done if PKIX-SSH dies / becomes unmaintained two
weeks after the Buster release. And this seems to be your only concern.

>                        (If somebody wants to package it separately for
>    the extra features, that's their affair, but it wouldn't solve the
>    problem at hand.)

I don't see a reason to package PKIX-SSH if OpenSSH (the root problem)
remains.

>  * Start a team to maintain an OpenSSL 1.1 compatibility layer myself.
>    Ingo Schwarze persuaded me on openssl-unix-dev that this was a bad
>    idea.  I would be happy if the OpenSSL developers carried this
>    forward as a proper project rather than just as an unversioned
>    tarball dump, but I'm not in a position to tell them what to do.

this unversioned tar file provides a handful accessors. Instead of
accessing ctx->keylength there is a function to be used. That function's
content is the direct access to the struct. I don't know what could be
there maintained except to add new functions now and then. You can't
have it as a .so library and it makes no sense to update that header
file because two helpers were added which you don't need. And I assume
that most project will drop that header file around 2020 once 1.0.2 gets
end of life (like a lot project dropped their 1.0.0 and earlier compat
layer while preparing for 1.1).

>  * Configure OpenSSH using --without-openssl, and use only its internal
>    crypto functions.  I mention this mainly for completeness, but if you
>    do this you only get a very limited feature set (e.g. only ED25519
>    keys); it's a long way off being viable.
So no RSA key authentification and probably no gssapi.

Sebastian

Message #237 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Guus Sliepen <guus@debian.org>

To: Toni Mueller <support@oeko.net>, 754513@bugs.debian.org, debian-devel@lists.debian.org, openssl@packages.debian.org

Subject: Re: Bug#754513: RFP: libressl -- SSL library, forked from OpenSSL

Date: Tue, 17 Oct 2017 00:05:30 +0200

[Message part 1 (text/plain, inline)]

On Mon, Oct 16, 2017 at 05:29:09PM +0100, Colin Watson wrote:

> > * Package name    : libressl
[...]
> Furthermore, the OpenSSL maintainers in Debian now want to drop their
> 1.0 compatibility packages, which the Debian OpenSSH packages rely on.
> I can't exactly fault them for wanting to reduce their maintenance
> burden, but it is going to put me in a very difficult position soon; and
> I assume that they don't actually want to break OpenSSH either.

Sounds like a great opportunity: the libressl package can fill the 1.0
API void left behind without libressl and openssl packages having to
conflict with each other (except possibly for the -dev packages).

Personally I think LibreSSL is in a much better shape than OpenSSL, and
despite fears of OpenBSD only caring about themselves, I have found that
it is easier to compile LibreSSL for various platforms (even non-POSIX
ones) than OpenSSL. And that APIs might be broken more easily by LibreSSL
is ridiculous, as it is OpenSSL iself that has changed its API in a
non-backwards compatible way that is now causing this discussion.

> The OpenSSH developers are starting to talk about bundling LibreSSL to
> avoid this problem [3], noting that OpenBSD and Apple already link
> OpenSSH against LibreSSL.  (Note that OpenSSH only uses libcrypto, not
> libssl, so while this has all the usual problems of bundling, the
> exposure isn't quite as horrific as it might first seem.)

I'd strongly favor having proper packages for LibreSSL. I'd happily
switch tinc over to depending on them instead of on OpenSSL packages.

>  * Take Kurt's patch to switch to the 1.1 API.  Fedora have done this.
>    I'm extremely reluctant to do this because it's a >3000-line patch
>    touching most of OpenSSH's cryptographic internals, which is bound to
>    produce lots of difficult conflicts on pretty much every new upstream
>    release.

If it was only needed temporarily until OpenSSH implemented OpenSSL 1.1
compatibility, I'd say fine, but if that's not going to happen, then I'd
avoid going down this road.

>  * Switch to PKIX-SSH, an OpenSSH fork with 1.1 support.  This fork adds
>    new features, making it a one-way transition.  With all due respect,
>    as far as I can tell it's a one-person fork with very limited uptake
>    compared to OpenSSH, and I don't think it would be wise to switch
>    Debian over to it.

I agree.

>  * Start a team to maintain an OpenSSL 1.1 compatibility layer myself.
>    Ingo Schwarze persuaded me on openssl-unix-dev that this was a bad
>    idea.  I would be happy if the OpenSSL developers carried this
>    forward as a proper project rather than just as an unversioned
>    tarball dump, but I'm not in a position to tell them what to do.

That sounds just as bad as maintaining a patch for OpenSSH to support
OpenSSL 1.1.

> Out of all of these, I think the option that I think has the fewest
> downsides overall is to convince people to package LibreSSL, but I'm not
> myself in a position to contribute to that effort.
> 
> Does anyone have thoughts or other options, or want to help?

Since I'd be a user of it I'd be willing to help.

-- 
Met vriendelijke groet / with kind regards,
      Guus Sliepen <guus@debian.org>

[signature.asc (application/pgp-signature, inline)]

Message #242 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: Guus Sliepen <guus@debian.org>, Toni Mueller <support@oeko.net>, 754513@bugs.debian.org, debian-devel@lists.debian.org, openssl@packages.debian.org

Subject: Re: Bug#754513: RFP: libressl -- SSL library, forked from OpenSSL

Date: Mon, 16 Oct 2017 22:21:10 -0400

On Tue, Oct 17, 2017 at 12:05:30AM +0200, Guus Sliepen wrote:
>despite fears of OpenBSD only caring about themselves, I have found that
>it is easier to compile LibreSSL for various platforms (even non-POSIX
>ones) than OpenSSL. And that APIs might be broken more easily by LibreSSL
>is ridiculous, as it is OpenSSL iself that has changed its API in a
>non-backwards compatible way that is now causing this discussion.

It is not ridiculous to point out that LibreSSL is released every six 
months and supported for one year after release, while OpenSSL is 
supported for at least 2 years, and 5 years for LTS releases. It's not 
unrealistic to think that a Debian stable could release with a LibreSSL 
that's already unsupported upstream. It is also not ridiculous to point 
out that a number of distributions have an interest in long term 
maintenance of released versions of OpenSSL, while there is no such 
community around LibreSSL.

You are correct, though, that the OpenSSL and LibreSSL code bases will 
continue to diverge, from both directions. I think that's the biggest 
impediment to creating an OpenSSL 1.0 compatability layer for 
OpenSSH--over time, neither OpenSSL nor LibreSSL have any interest in 
confining themselves to that API, and it's clear that OpenSSH will track 
LibreSSL's API rather than the old OpenSSL API in the long term.

As I continue to think about it, it may actually end up being better to 
embed a constrained subset of LibreSSL in OpenSSH than worry about 
either maintaining the entire LibreSSL package over a period of years, 
or fork.

Mike Stone

Message #247 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>

Cc: Toni Mueller <support@oeko.net>, 754513@bugs.debian.org, debian-devel@lists.debian.org, openssl@packages.debian.org

Subject: Re: Bug#754513: RFP: libressl -- SSL library, forked from OpenSSL

Date: Tue, 17 Oct 2017 11:51:19 +0100

On Mon, Oct 16, 2017 at 10:00:50PM +0200, Sebastian Andrzej Siewior wrote:
> On 2017-10-16 17:29:09 [+0100], Colin Watson wrote:
> > While there does exist a skeletal compatibility layer linked from the
> > upstream wiki [1], the OpenSSL developers explicitly don't want to
> > maintain this properly [2], and the OpenSSH developers say that it is
> > "unversioned, incomplete, barely documented, and seems to be
> > unmaintained" [3].  Kurt Roeckx proposed a patch to add a compatibility
> > shim [4], and a number of other projects have done something similar,
> > but the OpenSSH developers have explicitly said that they do not want to
> > take that approach [5].
> It has never been explained what it is that upstream wants. I get the
> impression, that they want a compat/shim layer and things have to work
>   https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-November/035456.html
>   https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-November/035497.html

Ingo replied to me privately (but giving me permission to use the
information any way I saw fit) with this:

  Here is one example of a posting where it is explained
  in a comment:
  
    https://plus.google.com/u/0/+IngoSchwarze/posts/WQ9ouupTVgx
  
  In other words, an officially maintained library that *uses* the
  OpenSSL-1.0 API (i.e. links against existing existing libcrypto
  lbraries) and that *exports* the OpenSSL-1.1 API for application
  programs to link against, such that application programs using the
  OpenSSL-1.1 API can run on systems providing an OpenSSL-1.0 library.

> I didn't even figure out if they want to alter their code or not.

  https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036370.html

> > It's not currently clear to me whether anyone has explicitly talked with
> > the OpenSSL developers about this problem from the point of view of the
> > OpenSSH developers, rather than just as users trying to get OpenSSH to
> > compile against the new version.
> 
> Kurt is aware of the situation, he is part of upstream. It might be that
> OpenSSH is playing hard to get.

I don't see any benefit in conducting a discussion in which we assume
bad faith.  There are different opinions on what makes for a good API
transition, and pressures coming from different choices upstream
(remembering that Debian's immediate upstream for OpenSSH is OpenSSH
Portable, which itself has OpenBSD as an upstream) and from available
development and review time, but simplifying that as "playing hard to
get" isn't particularly helpful.

> > At the moment I can see the following somewhat realistic paths forward:
> > 
> >  * Accept an upstream bundling of LibreSSL (still hypothetical, but
> >    plausible).  I'm sure this would also not be the security team's
> >    favourite outcome, although presumably only a subset of LibreSSL CVEs
> >    would apply to OpenSSH, and it wouldn't be making it available as a
> >    general-purpose library.
> 
> 4.13. Convenience copies of code

I helped to draft that section, so I'm aware of what it says.  Note that
it's a "should", and that it's not currently in the list of release
standards for packages in buster
(https://release.debian.org/buster/rc_policy.txt).  According to our
current policy standards, it would certainly be a bug to have an
embedded copy, it might well make various people cross with me, but it's
something we're allowed to trade off against other considerations if
they're sufficiently compelling.

We could, for example, reasonably embed LibreSSL for a while and then
switch to an externally-packaged library if it looks like API stability
will be good enough for our needs.

-- 
Colin Watson                                       [cjwatson@debian.org]

Message #252 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: 754513@bugs.debian.org, debian-devel@lists.debian.org, openssl@packages.debian.org

Subject: Re: Bug#754513: RFP: libressl -- SSL library, forked from OpenSSL

Date: Tue, 17 Oct 2017 12:18:12 +0100

On Mon, Oct 16, 2017 at 01:07:43PM -0400, Michael Stone wrote:
> My understanding is that the libressl project does not support a release for
> the length of a debian release cycle, and does not commit to API stability
> for debian-cycle periods.

The LibreSSL website currently says one year.

One relevant data point is that OpenSSH 7.6p1 seems to build and run
fine against LibreSSL 2.0.0 (the first public release, from July 2014),
so I'm not very concerned about API stability from the point of view of
OpenSSH.  Your wider concerns may well be reasonable for an
externally-packaged library though; I don't have enough experience with
SSL library maintenance to be able to say.

-- 
Colin Watson                                       [cjwatson@debian.org]

Message #257 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Guus Sliepen <guus@debian.org>

To: Toni Mueller <support@oeko.net>, 754513@bugs.debian.org, debian-devel@lists.debian.org, openssl@packages.debian.org

Subject: Re: Bug#754513: RFP: libressl -- SSL library, forked from OpenSSL

Date: Tue, 17 Oct 2017 22:26:06 +0200

[Message part 1 (text/plain, inline)]

On Mon, Oct 16, 2017 at 10:21:10PM -0400, Michael Stone wrote:

> On Tue, Oct 17, 2017 at 12:05:30AM +0200, Guus Sliepen wrote:
> > despite fears of OpenBSD only caring about themselves, I have found that
> > it is easier to compile LibreSSL for various platforms (even non-POSIX
> > ones) than OpenSSL. And that APIs might be broken more easily by LibreSSL
> > is ridiculous, as it is OpenSSL iself that has changed its API in a
> > non-backwards compatible way that is now causing this discussion.
> 
> It is not ridiculous to point out that LibreSSL is released every six months
> and supported for one year after release, while OpenSSL is supported for at
> least 2 years, and 5 years for LTS releases.

That is certainly not ridiculous. But, I had a look at the release plan
for OpenSSL at https://www.openssl.org/policies/releasestrat.html, and
it seems there only is one LTS release, namely 1.0.2, which will be
supported until the very end of 2019. 1.1.0 is only supported until
September 2018. In that context it is strange that we switched to 1.1.0
in stretch already. Let's hope there is an LTS for 1.1.x in time for
buster.

> It's not unrealistic to think
> that a Debian stable could release with a LibreSSL that's already
> unsupported upstream. It is also not ridiculous to point out that a number
> of distributions have an interest in long term maintenance of released
> versions of OpenSSL, while there is no such community around LibreSSL.

Maybe not currently for Debian or Fedora derivatives, but some
distributions (Alpine, OpenELEC amongst others) have switched to
LibreSSL as the default, and some (Gentoo, unsurprisingly) have it as an
option.

I see two main forces determining which fork of a library will be used:
either distributions themselves will choose based on technical and other
merits, or important applications will favor one of the forks, forcing
the decision for distributions. OpenSSH is now applying some force, I
have no idea what programs are out there that can only work with
OpenSSL. I assume those that moved to OpenSSL 1.1 and ditched OpenSSL
1.0 compatibility, but I wonder how many there are.

It would be interesting to recompile all packages that Build-Depend:
libssl-dev with LibreSSL, and see what actually breaks...

> As I continue to think about it, it may actually end up being better to
> embed a constrained subset of LibreSSL in OpenSSH than worry about either
> maintaining the entire LibreSSL package over a period of years, or fork.

I don't see why it couldn't be in its own package even if OpenSSH was
the only user. It doesn't change the maintenance burden.

-- 
Met vriendelijke groet / with kind regards,
      Guus Sliepen <guus@debian.org>

[signature.asc (application/pgp-signature, inline)]

Message #262 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>

To: Toni Mueller <support@oeko.net>, 754513@bugs.debian.org, debian-devel@lists.debian.org, openssl@packages.debian.org

Subject: Re: Bug#754513: RFP: libressl -- SSL library, forked from OpenSSL

Date: Tue, 17 Oct 2017 23:56:52 +0200

On 2017-10-17 11:51:19 [+0100], Colin Watson wrote:
> > I didn't even figure out if they want to alter their code or not.
> 
>   https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036370.html

let me check.

> I don't see any benefit in conducting a discussion in which we assume
> bad faith.  There are different opinions on what makes for a good API
> transition, and pressures coming from different choices upstream
> (remembering that Debian's immediate upstream for OpenSSH is OpenSSH
> Portable, which itself has OpenBSD as an upstream) and from available
> development and review time, but simplifying that as "playing hard to
> get" isn't particularly helpful.

I'm sorry.

Sebastian

Message #267 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: Guus Sliepen <guus@debian.org>, Toni Mueller <support@oeko.net>, 754513@bugs.debian.org, debian-devel@lists.debian.org, openssl@packages.debian.org

Subject: Re: Bug#754513: RFP: libressl -- SSL library, forked from OpenSSL

Date: Tue, 17 Oct 2017 19:57:43 -0400

On Tue, Oct 17, 2017 at 10:26:06PM +0200, Guus Sliepen wrote:
>On Mon, Oct 16, 2017 at 10:21:10PM -0400, Michael Stone wrote:
>> On Tue, Oct 17, 2017 at 12:05:30AM +0200, Guus Sliepen wrote:
>> > despite fears of OpenBSD only caring about themselves, I have found that
>> > it is easier to compile LibreSSL for various platforms (even non-POSIX
>> > ones) than OpenSSL. And that APIs might be broken more easily by LibreSSL
>> > is ridiculous, as it is OpenSSL iself that has changed its API in a
>> > non-backwards compatible way that is now causing this discussion.
>>
>> It is not ridiculous to point out that LibreSSL is released every six months
>> and supported for one year after release, while OpenSSL is supported for at
>> least 2 years, and 5 years for LTS releases.
>
>That is certainly not ridiculous. But, I had a look at the release plan
>for OpenSSL at https://www.openssl.org/policies/releasestrat.html, and
>it seems there only is one LTS release, namely 1.0.2, which will be
>supported until the very end of 2019. 1.1.0 is only supported until
>September 2018. In that context it is strange that we switched to 1.1.0
>in stretch already. Let's hope there is an LTS for 1.1.x in time for
>buster.

I'd expect a 1.1.1 release with a relatively small delta (no major API 
changes, and a relatively straightforward backporting effort) from 1.1. 
The LTS is most valuable for an API branch no longer being actively 
developed, and if 1.1.1 was followed by 1.2, I'd expect LTS for 1.1.1.

>> It's not unrealistic to think
>> that a Debian stable could release with a LibreSSL that's already
>> unsupported upstream. It is also not ridiculous to point out that a number
>> of distributions have an interest in long term maintenance of released
>> versions of OpenSSL, while there is no such community around LibreSSL.
>
>Maybe not currently for Debian or Fedora derivatives, but some
>distributions (Alpine, OpenELEC amongst others) have switched to
>LibreSSL as the default, and some (Gentoo, unsurprisingly) have it as an
>option.

Without getting into a discussion of various distributions, suffice it 
to say that these are not ones known for long term binary support.

>> As I continue to think about it, it may actually end up being better to
>> embed a constrained subset of LibreSSL in OpenSSH than worry about either
>> maintaining the entire LibreSSL package over a period of years, or fork.
>
>I don't see why it couldn't be in its own package even if OpenSSH was
>the only user. It doesn't change the maintenance burden.

Because the parts of libressl used in openssh (a subset of libcrypto) 
historically have had fewer problems then the mess of stuff in libssl.  
The attack surface of that subset of functions in ssh is a lot lower 
than "any package that uses ssl and happens to link to libressl".

Mike Stone

Message #272 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Harald Dunkel <harri@afaics.de>

To: 754513@bugs.debian.org

Subject: Re: RFP: libressl -- SSL library, forked from OpenSSL

Date: Sun, 20 Jan 2019 13:40:09 +0100

metoo. I'd love to see libressl available for Debian. Newer versions of
opensmtpd (coming from the OpenBSD world as well) dropped support for
openssl in favor of libressl, see.

https://poolp.org/posts/2018-11-03/opensmtpd-released-and-upcoming-filters-preview/

Regards
Harri

Message #279 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Stefania Wilson <stefania.wilson@theired.org>

To: 754513@bugs.debian.org

Subject: Paper Submission - Thailand IRED International Conference - August 2019

Date: Tue, 21 May 2019 22:13:52 +0000

[Message part 1 (text/plain, inline)]

Dear Friends,


We would like to invite you to submit research article in the 9th Joint International Conference organised by Institute of Research Engineers and Doctors at Bangkok, Thailand. The theme for the 2019 Thailand conference is to bring together innovative academics and industrial experts to a common forum. We would be delighted to have you present at this conference to hear what the technology experts and researchers have to share about the technology advancements and their impact on our daily lives.


Joint International Conference Consists of following tracks:



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ0kZOkA8zwmBw5059xFSw23aX4SAORUOgHwPLRUeVWuJLnuKKxAXPiWhrGzQEt2djLiKd0WMgrYaiJz7OYYck79MG_inkNQNIlK6vY0LRsEK9Q2>
Track 1: 9th International Conference on Advances in Computing, Electronics and Communication - ACEC

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ0kZOkA8zwmBw5059xFSw23aX4SAORUOgHwPLRUeVWuJTtXmNH8L4MPUeEZPAI5QAX17xaCGy9Gl7KDsUTQeQfRtgPQ6nNCKEv8fmq8xFXlNbQ2>
Official Website: www.acec.theired.org



<http://tracking.theired.org/tracking/click?d=BWpoVaFv7Pbn0M65fQyf_XY3oA3MzLnKtXDQbwXQ5AzWz167TACqqifSy4d8r9-5Xi_CWyxttRjwCRYhmpptEzIA71hdDFKm2-595FeP8vRZrB0jA-3WT8Cnex6rP2TKwQ2>
Track 2: 9th International Conference On Advances in Civil, Structural and Environmental Engineering - ACSEE

<http://tracking.theired.org/tracking/click?d=BWpoVaFv7Pbn0M65fQyf_XY3oA3MzLnKtXDQbwXQ5AzWz167TACqqifSy4d8r9-50egmeC5eGyZLecWM0bo6soV_onBsKn52JHCCzajcwv3wlf7rceMgJTJLdSjWMvG81w2>
Official Website: www.acsee.theired.org



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ1EFCqSVXRKP8-d33R9Jfv8nuUIXiKXGJyKgPipN48TMPNuaQMNAFnhCkTPS0MCjnzlwE-6gUH4xS9eOdrKtOaojgAMMOQj6CR_wkX6EVGyF-Q2>
Track 3: 9th International Conference On Advances in Mechanical and Robotics Engineering - AMRE

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ1EFCqSVXRKP8-d33R9Jfv8nuUIXiKXGJyKgPipN48TM1v9K3BGbHedQk6mMecyg7wN91L7EfCHvdOGLAZeznHSl1VlnrBKSlgJ1U_Yoyvif3A2>
Official Website: www.amre.theired.org



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ6vygbBb3Xk_s1tXPjRxL-9O219jxjbsYQ2tdWrB0rhuovVdwDCWX8Jmmzw6bAb1s6AdVcmtmtYHzty0yZTAZh8prgg4z364j3Vva_0zDZnPzA2>
Track 4: 9th International Conference On Advances in Social Science, Management and Human Behaviour - SMHB

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ6vygbBb3Xk_s1tXPjRxL-9O219jxjbsYQ2tdWrB0rhuF5w8UJ0tfOjViakOsamZp_SmVORD0_vLLgyQfUHu3YNT4WQiC0mH-Pf1lqzC7Gu0Kg2>
Official Website: www.smhb.theired.org


Conference Venue: Hotel Lebua at State Tower, Bangkok, Thailand


Conference Date: 03 - 04 August 2019


Abstract/ Full Paper Submission For Review: 10 June 2019




About Publication:

All the registered papers will proudly be published by IRED-CPS and stored in the SEEK digital Library 
<http://tracking.theired.org/tracking/click?d=1pvogq7UozbvCOeMr_RdFhcnr0XCagTCd8xvCHyt1vGIfyiyIvhm-TW2ju6CvfrgK8gt8iXU5ojOVJ8pm92xReyu_ImUQA9bJzjBgYEzU9M9kMWvUAHWpPrtYtcn_rHT3A2>
(www.seekdl.org). Each Paper will be assigned DOI (Digital Object Identifier) from CROSSREF. The Proc. will be submitted to ISI Thomson for Review and Indexing. Proc. will also be published in International Journals with ISSN Numbers.


Remote Presentation via Skype can also be arranged.


We would also like to share some conference photographs of previous held International conference that has been worldwide.


Kindly refer to the below link to access the conference photographs.

<http://tracking.theired.org/tracking/click?d=Yc8Niga1PEek6kjwbnvKhxolNzm1nz5ClcB7_yzWKsZffGm3ZdHBDUf2F7hYW03qCP4FEvmMkLxSFHg9ixvabX-RL38m_KW58aqI5sQ-bhcS8ySv0V4CC8QoRPGFIbReGDtIbZH1FmV1B_0oz9NNrTU1>

<http://tracking.theired.org/tracking/click?d=1pvogq7UozbvCOeMr_RdFsMnj-CAjt3iR8vsZa-g7QfwukYUcHvAWr2pTPTjqSl1T0LLljYzFP83IQToZa8SylITjnYMPHjaqp7ChH2dnUZBTB1TUdg56AZTTfs_W6Xcjg2>
https://gallery.theired.org/previous-conferences/



We Request you to forward this email to your colleagues/Researchers/students in order to promote the conference.


The aim of the conference is to provide a platform to the researchers and practitioners from both academia as well as industry to meet and share cutting-edge development in the field.
Please take the time to explore the website for more details, check on important dates, and keep yourself up to date on recent changes. 



Registered Papers (IRED Extended paper guidelines applicable) will be published in the various issues of International journals.
Prospective authors are invited to submit full (original) research papers; which are NOT submitted or published or under consideration anywhere in other conferences or journals; in electronic format via email. 




Thanks Much 
Stefania Wilson
NEWS Division 
IRED
 If you no longer wish to receive mail from us, you can 
<http://tracking.theired.org/tracking/unsubscribe?msgid=zu0MmoxyNd1G7z6jLv-n7A2>
unsubscribe
IRED Headquarter, 42 Broadway, Suite 12-217, New York,
									NY 10004, USA
								
Tel: +1-(212) 901-3781
									|  Fax: +1-(212) 901-3786
								

[Message part 2 (text/html, inline)]

Message #284 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Stefania Wilson <stefania.wilson@theired.org>

To: 754513@bugs.debian.org

Subject: Paper Submission - CFP International Conference @ University of Westminster, London, UK

Date: Wed, 22 May 2019 22:00:51 +0000

[Message part 1 (text/plain, inline)]

Dear Friends,


We would like to invite you to submit research article in the 9th Joint International Conference organised by Institute of Research Engineers and Doctors at University of Westminster, London, UK. The theme for the 2019 UK conference is to bring together innovative academics and industrial experts to a common forum. We would be delighted to have you present at this conference to hear what the technology experts and researchers have to share about the technology advancements and their impact on our daily lives.


Joint International Conference Consists of following tracks:



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJyU_aMDrx6JCbEXXFdsmgXMnXY-rigg41rnQVz0bZDxGeQW5GQmRL4oPh0b3mWZpLhpTiUjxbiwND5JHUPr89MYRTCicX_dM_mNq9bVWxNskow2>
Track 1: 9th International Conference on Advances in Computing, Control and Networking - ACCN

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJyU_aMDrx6JCbEXXFdsmgXMnXY-rigg41rnQVz0bZDxGAne1oHviImgAw0K5kGSXjpJNHnyaRqfAIPL4RVbhrNozsKilDQPXlb6AKpGvrcFR8w2>
Official Webiste: www.accn.theired.org



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ-66gin6ghmi_nTQ8RWvRbjg4nrDouzpvCTS69qAbYp98b3QagV943Lq9BzyOPbvi7zGGiqlSaIyxdVONYoEBTu0JN29iDcZnjj1qFyclxqSdQ2>
Track 2: 9th International Conference On Advances in Civil, Structural and Mechanical Engineering - ACSM

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ-66gin6ghmi_nTQ8RWvRbjg4nrDouzpvCTS69qAbYp9lQs0x6eLZUQmCPtY159ACwhpRM5kGiibTr14ylE7T8os8cjU9N92LHZduuv7sO9TuA2>
Official Webiste: www.acsm.theired.org



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ79lbEBkJHofgsE-G4EmRkodJM2BaYPj7SjnMq1WsmS-Crfgj_mhjfCQ0mCGtuxx-B9MolglnMXiJuXhaeQcraJ1TdrPbpfiSxjDlMzkuoYYng2>
Track 3: 9th International Conference On Advances in Applied Science and Environmental Technology - ASET

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ79lbEBkJHofgsE-G4EmRkodJM2BaYPj7SjnMq1WsmS-u3OMWOiYQi2un5oPSbjKG05w4v2z_tnFOAs_fJnyOBuvAr2RphtOx4UCnZir2T2mHA2>
Official Webiste: www.aset.theired.org



<http://tracking.theired.org/tracking/click?d=QM81x6k1RxgNs031BT7L67rYPp4ChBKmPGLUl-R67pOOZc1EIXvH5UOxuh54IONbXM0rn9NkzEW3yvzYPsxxQhW-ims9LoeIMEUszHpH_Dcfl10jJi222xIdFjx_8kKYmw2>
Track 4: 9th International Conference On Advances in Economics, Social Science and Human Behaviour Study - ESSHBS​
<http://tracking.theired.org/tracking/click?d=9z9hOpXCgxLxIZYyyr-71J7OaA-h7vIfrRdr87efQLiD3IgPa7w7JrGg-rYERxn_A4DyRyX4JMMT2K3Uiiwk4Rc01USwzaKCUqCBGFg8Fu0oRYnh8TNISb5uJviFUiDNLA2>


<http://tracking.theired.org/tracking/click?d=QM81x6k1RxgNs031BT7L67rYPp4ChBKmPGLUl-R67pOOZc1EIXvH5UOxuh54IONb8YuF5mOCRLITSEanXvU6Cadyjv31styGfkxTJZQi5rhAEQ7vjMBywTV9LgKMMH1K2g2>
Official Webiste: www.esshbs.theired.org​




Conference Venue: University of Westminster, London, UK


Conference Date: 20 - 21 July 2019


Abstract/ Full Paper Submission For Review: 10 June 2019





About University of Westminster (Conference Venue):
--The University of Westminster is a public university in London, United Kingdom. Its antecedent institution, the Royal Polytechnic Institution, was founded in 1838 and was the first polytechnic institution in the UK. Westminster was awarded university status in 1992 meaning it could award its own degrees.


--Its headquarters and original campus are in Regent Street in the City of Westminster area of central London, with additional campuses in Fitzrovia, Marylebone and Harrow. It operates the Westminster International University in Tashkent in Uzbekistan.


--Westminster's academic activities are organised into seven faculties and schools, within which there are around 45 departments. The University has numerous centres of research excellence across all the faculties, including the Communication and Media Research Institute, whose research is ranked in the Global Top 40 by the QS World University Rankings. Westminster had an income of £170.4 million in 2012/13, of which £4.5 million was from research grants and contracts.


--Westminster is a member of the Association of Commonwealth Universities, the Association of MBAs, EFMD, the European University Association and Universities UK.


About Publication:​

All the registered papers will proudly be published by IRED-CPS and stored in the SEEK digital Library 
<http://tracking.theired.org/tracking/click?d=1pvogq7UozbvCOeMr_RdFhcnr0XCagTCd8xvCHyt1vHHzhTIg_GBgJEgxcSdkZeewzEXebcaSJ9tvAuc9Jv94OSEohScqv4LK07snbazhj-dgHrpR9j7lOtm2AiIdIeppw2>
(www.seekdl.org). Each Paper will be assigned DOI (Digital Object Identifier) from CROSSREF. The Proc. will be submitted to ISI Thomson for Review and Indexing. Proc. will also be published in International Journals with ISSN Numbers.


Remote Presentation via Skype can also be arranged.


We would also like to share some conference photographs of previous held International conference that has been worldwide.


Kindly refer to the below link to access the conference photographs.

<http://tracking.theired.org/tracking/click?d=Yc8Niga1PEek6kjwbnvKhxolNzm1nz5ClcB7_yzWKsZffGm3ZdHBDUf2F7hYW03qKLAk65iSiRdpJ8c3SD_WMHrHSCTFUA6Mu8zgNO_K97B1pRJc4Kq7wQESsm24gdsdIvJ8fBZhh597eiefSGzP4Ro1>

<http://tracking.theired.org/tracking/click?d=1pvogq7UozbvCOeMr_RdFsMnj-CAjt3iR8vsZa-g7QfOKlLdOWuN_cb0KYxRyvnnUWZ4IODFN4PdNxI7EmOQ3ouWNsZ-6QMe9HfBKaspaPMrN4JA_4rF2a0LRyr6AtPlhA2>
https://gallery.theired.org/previous-conferences/



We Request you to forward this email to your colleagues/Researchers/students in order to promote the conference.


The aim of the conference is to provide a platform to the researchers and practitioners from both academia as well as industry to meet and share cutting-edge development in the field.
Please take the time to explore the website for more details, check on important dates, and keep yourself up to date on recent changes. 



Registered Papers (IRED Extended paper guidelines applicable) will be published in the various issues of International journals.
Prospective authors are invited to submit full (original) research papers; which are NOT submitted or published or under consideration anywhere in other conferences or journals; in electronic format via email. 




Thanks Much 
Stefania Wilson
NEWS Division 
IRED
 If you no longer wish to receive mail from us, you can 
<http://tracking.theired.org/tracking/unsubscribe?msgid=W7z_P8zmoB16PhZBTbqrcg2>
unsubscribe
IRED Headquarter, 42 Broadway, Suite 12-217, New York,
									NY 10004, USA
								
Tel: +1-(212) 901-3781
									|  Fax: +1-(212) 901-3786
								

[Message part 2 (text/html, inline)]

Message #289 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Stefania Wilson <stefania.wilson@theired.org>

To: 754513@bugs.debian.org

Subject: Paper Submission - Thailand IRED International Conference - August 2019

Date: Sat, 25 May 2019 19:05:39 +0000

[Message part 1 (text/plain, inline)]

Dear Friends,


We would like to invite you to submit research article in the 9th Joint International Conference organised by Institute of Research Engineers and Doctors at Bangkok, Thailand. The theme for the 2019 Thailand conference is to bring together innovative academics and industrial experts to a common forum. We would be delighted to have you present at this conference to hear what the technology experts and researchers have to share about the technology advancements and their impact on our daily lives.


Joint International Conference Consists of following tracks:



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ0kZOkA8zwmBw5059xFSw21OOXu7T_6eV1rIBk_rLwWwNoCr6uEDERAaHvk8TduccMpShPq2GJSoRTBiMyrgw9yKGVQ3CsZ0Y_fTVN0NF7BsiQ2>
Track 1: 9th International Conference on Advances in Computing, Electronics and Communication - ACEC

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ0kZOkA8zwmBw5059xFSw21OOXu7T_6eV1rIBk_rLwWw897bZm7DS_z4cwHOePRgZSbbaDJZbz6t4uVIwxtucPqzg9-9fHQMNdep6bzXVuV57A2>
Official Website: www.acec.theired.org



<http://tracking.theired.org/tracking/click?d=BWpoVaFv7Pbn0M65fQyf_XY3oA3MzLnKtXDQbwXQ5AwIeVaefrr1ex97QMNtpuooMVqJmlrC5YYDK9N71PWUQdeMXQS8QUfrBa6jpASyTBLpCPqiIfJuc1qN2DbaWEyZ2w2>
Track 2: 9th International Conference On Advances in Civil, Structural and Environmental Engineering - ACSEE

<http://tracking.theired.org/tracking/click?d=BWpoVaFv7Pbn0M65fQyf_XY3oA3MzLnKtXDQbwXQ5AwIeVaefrr1ex97QMNtpuoo6hkhmx_HZhw2sO3zBeMExBCeWbrd8luu5PFJKG4uAi48FUEOtLk6CiCQJFd-X8h43w2>
Official Website: www.acsee.theired.org



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ1EFCqSVXRKP8-d33R9Jfv9ui_d9qRq_MbysdLtFtK_TuTJtsWeimNQN6_w0065KI_q5gvgng4j8ag54E0ERZ8LcftdKxEQFg2Snsa9hpGcGiQ2>
Track 3: 9th International Conference On Advances in Mechanical and Robotics Engineering - AMRE

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ1EFCqSVXRKP8-d33R9Jfv9ui_d9qRq_MbysdLtFtK_TiWfHpBNR5faCYan95Fd3Pn4y1MefyjldCVpgifC1MyZufmdHq0T8Gz6dA9eYpAMKeQ2>
Official Website: www.amre.theired.org



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ6vygbBb3Xk_s1tXPjRxL--LnlCEkN5b-32511fefdGdpCbn7TA4F2Ma-aTvXirpiEtbCNcvx5kjJwd-Xp_JHeUMTbbHO8vnCZJkFOmTe08NXQ2>
Track 4: 9th International Conference On Advances in Social Science, Management and Human Behaviour - SMHB

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ6vygbBb3Xk_s1tXPjRxL--LnlCEkN5b-32511fefdGd0-FvD1nDZ_4G8MEEpWW8hFIzVQRGA5dTmmB0uuJ3ea3ViA3nYJgwsACqmIeAEFN8Kw2>
Official Website: www.smhb.theired.org


Conference Venue: Hotel Lebua at State Tower, Bangkok, Thailand


Conference Date: 03 - 04 August 2019


Abstract/ Full Paper Submission For Review: 10 June 2019




About Publication:

All the registered papers will proudly be published by IRED-CPS and stored in the SEEK digital Library 
<http://tracking.theired.org/tracking/click?d=1pvogq7UozbvCOeMr_RdFhcnr0XCagTCd8xvCHyt1vFM4VF_XW0i0c2lTxblBrkjNrGGcl2_hFZs16xU12UNSCwVw4SRvPcXubgkj24m4K3XK8crIbQn91DGacE611Z8tw2>
(www.seekdl.org). Each Paper will be assigned DOI (Digital Object Identifier) from CROSSREF. The Proc. will be submitted to ISI Thomson for Review and Indexing. Proc. will also be published in International Journals with ISSN Numbers.


Remote Presentation via Skype can also be arranged.


We would also like to share some conference photographs of previous held International conference that has been worldwide.


Kindly refer to the below link to access the conference photographs.

<http://tracking.theired.org/tracking/click?d=Yc8Niga1PEek6kjwbnvKhxolNzm1nz5ClcB7_yzWKsZffGm3ZdHBDUf2F7hYW03qM6zv0WyCMfmTxkKWqVaq9uUQd69DCVXI8FrEUiQr-FaInKPRFCtCOkW1Fxf3ZFlin9R4b56KvvQmhQuK_rGGJqY1>

<http://tracking.theired.org/tracking/click?d=1pvogq7UozbvCOeMr_RdFsMnj-CAjt3iR8vsZa-g7QdhB-VYdK9Zq_u2gdVI3_X-S6vAH3fnNcIIskj50lxCZ26hFVQvQAjogbjEv3H1D8DBc8D5pTebuvTmNePreQFzGw2>
https://gallery.theired.org/previous-conferences/



We Request you to forward this email to your colleagues/Researchers/students in order to promote the conference.


The aim of the conference is to provide a platform to the researchers and practitioners from both academia as well as industry to meet and share cutting-edge development in the field.
Please take the time to explore the website for more details, check on important dates, and keep yourself up to date on recent changes. 



Registered Papers (IRED Extended paper guidelines applicable) will be published in the various issues of International journals.
Prospective authors are invited to submit full (original) research papers; which are NOT submitted or published or under consideration anywhere in other conferences or journals; in electronic format via email. 




Thanks Much 
Stefania Wilson
NEWS Division 
IRED
 If you no longer wish to receive mail from us, you can 
<http://tracking.theired.org/tracking/unsubscribe?msgid=O6wzWAia8cvqT_P5LHOpkw2>
unsubscribe
IRED Headquarter, 42 Broadway, Suite 12-217, New York,
									NY 10004, USA
								
Tel: +1-(212) 901-3781
									|  Fax: +1-(212) 901-3786
								

[Message part 2 (text/html, inline)]

Message #294 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Stefania Wilson <stefania.wilson@theired.org>

To: 754513@bugs.debian.org

Subject: Paper Submission - CFP International Conference @ University of Westminster, London, UK

Date: Mon, 27 May 2019 12:30:52 +0000

[Message part 1 (text/plain, inline)]

Dear Friends,


We would like to invite you to submit research article in the 9th Joint International Conference organised by Institute of Research Engineers and Doctors at University of Westminster, London, UK. The theme for the 2019 UK conference is to bring together innovative academics and industrial experts to a common forum. We would be delighted to have you present at this conference to hear what the technology experts and researchers have to share about the technology advancements and their impact on our daily lives.


Joint International Conference Consists of following tracks:



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJyU_aMDrx6JCbEXXFdsmgXOrwrK90sPdmzEbqcbxFDQJ1x5ujWJsu_YCI-rOR0qqnoez3jHgCuTdRBZRIpS_PvRnP2Uo0e05tdBk5loDKFmj1w2>
Track 1: 9th International Conference on Advances in Computing, Control and Networking - ACCN

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJyU_aMDrx6JCbEXXFdsmgXOrwrK90sPdmzEbqcbxFDQJgH5VrX2lsJfUs9B4jFxG1abGJ7xalR7OSDb5ngB5Pg6eZktbiEBxQtBw6NgIpyFUeg2>
Official Webiste: www.accn.theired.org



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ-66gin6ghmi_nTQ8RWvRbi4NdyoMBREKAYE-BILekSXULDGeP_EtfKMo3JqTRxuoP8d9bo5TS5WvWK9pq_2_bA0ODZBQ0NWxvGdAdOcNGVctg2>
Track 2: 9th International Conference On Advances in Civil, Structural and Mechanical Engineering - ACSM

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ-66gin6ghmi_nTQ8RWvRbi4NdyoMBREKAYE-BILekSXjDhvu6a-8YdPE8qB8Zsyc2Z3bks922mScDqLRIu7NFhYpNsXsG2fQN1EegaZUI8HEQ2>
Official Webiste: www.acsm.theired.org



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ79lbEBkJHofgsE-G4EmRkrpU8CVFf-nHPkM_VObP3rpNSssTDmXeMSOR9d351ow0vSygJ0Yr7ePxrVGdhSgFx8OB00GG_Q3N1XrRIHK_Qajqw2>
Track 3: 9th International Conference On Advances in Applied Science and Environmental Technology - ASET

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ79lbEBkJHofgsE-G4EmRkrpU8CVFf-nHPkM_VObP3rpzr-x24NhMtIvGjHIMdNyJLB7uCVisQKwJ1UQTEQ5O9bSj5y1K9EF5z9vVVJdTqa6IA2>
Official Webiste: www.aset.theired.org



<http://tracking.theired.org/tracking/click?d=QM81x6k1RxgNs031BT7L67rYPp4ChBKmPGLUl-R67pNZCLBTB0Qkq4wd0S06UJ6LeRLgq0uHRPF_j4rci52xIgDWwS35YnvSMGEs_dIgUtLqKDlXvjSDvLfomKQn9MSwtA2>
Track 4: 9th International Conference On Advances in Economics, Social Science and Human Behaviour Study - ESSHBS​
<http://tracking.theired.org/tracking/click?d=9z9hOpXCgxLxIZYyyr-71J7OaA-h7vIfrRdr87efQLghXOlVrLETbWVxsZb8lhvqwXSwWKjkelGGrAp89bXo9waSnEOUOZuLr8-kBAunueXTWOj6w1UPxak1ZB8hF6IvBg2>


<http://tracking.theired.org/tracking/click?d=QM81x6k1RxgNs031BT7L67rYPp4ChBKmPGLUl-R67pNZCLBTB0Qkq4wd0S06UJ6LligDNnXXzPXWujBHhzLYiKUp8RVS00DE5RkFmG2uua018PEIeotMGJcIVP66kxLsrw2>
Official Webiste: www.esshbs.theired.org​




Conference Venue: University of Westminster, London, UK


Conference Date: 20 - 21 July 2019


Abstract/ Full Paper Submission For Review: 10 June 2019





About University of Westminster (Conference Venue):
--The University of Westminster is a public university in London, United Kingdom. Its antecedent institution, the Royal Polytechnic Institution, was founded in 1838 and was the first polytechnic institution in the UK. Westminster was awarded university status in 1992 meaning it could award its own degrees.


--Its headquarters and original campus are in Regent Street in the City of Westminster area of central London, with additional campuses in Fitzrovia, Marylebone and Harrow. It operates the Westminster International University in Tashkent in Uzbekistan.


--Westminster's academic activities are organised into seven faculties and schools, within which there are around 45 departments. The University has numerous centres of research excellence across all the faculties, including the Communication and Media Research Institute, whose research is ranked in the Global Top 40 by the QS World University Rankings. Westminster had an income of £170.4 million in 2012/13, of which £4.5 million was from research grants and contracts.


--Westminster is a member of the Association of Commonwealth Universities, the Association of MBAs, EFMD, the European University Association and Universities UK.


About Publication:​

All the registered papers will proudly be published by IRED-CPS and stored in the SEEK digital Library 
<http://tracking.theired.org/tracking/click?d=1pvogq7UozbvCOeMr_RdFhcnr0XCagTCd8xvCHyt1vGCW5jvO2Ao1cmy0WHmyajKdHwo9RPJpUe1OVXrPkvimKFao3KEbSe2bDVG5NnpajXlpmDQru7N-NXuCNLYwry6Jw2>
(www.seekdl.org). Each Paper will be assigned DOI (Digital Object Identifier) from CROSSREF. The Proc. will be submitted to ISI Thomson for Review and Indexing. Proc. will also be published in International Journals with ISSN Numbers.


Remote Presentation via Skype can also be arranged.


We would also like to share some conference photographs of previous held International conference that has been worldwide.


Kindly refer to the below link to access the conference photographs.

<http://tracking.theired.org/tracking/click?d=Yc8Niga1PEek6kjwbnvKhxolNzm1nz5ClcB7_yzWKsZffGm3ZdHBDUf2F7hYW03qZ8vjSBw9-H1ruGX7ZqEfy5J38yyP3ZLBGfNAGwvGL7kId2Pjo4tU_fVjuHJnvSmTXHpLyc6pyOKAjyK31IuVMqM1>

<http://tracking.theired.org/tracking/click?d=1pvogq7UozbvCOeMr_RdFsMnj-CAjt3iR8vsZa-g7Qd8612KqpU-cc_ExasuoCXaP6zsz7ZkgwT0ONOIP8TFtqfHLna_wMtQrzCIzul8obAxV-U8b0c44DzS_W_EgAxUBg2>
https://gallery.theired.org/previous-conferences/



We Request you to forward this email to your colleagues/Researchers/students in order to promote the conference.


The aim of the conference is to provide a platform to the researchers and practitioners from both academia as well as industry to meet and share cutting-edge development in the field.
Please take the time to explore the website for more details, check on important dates, and keep yourself up to date on recent changes. 



Registered Papers (IRED Extended paper guidelines applicable) will be published in the various issues of International journals.
Prospective authors are invited to submit full (original) research papers; which are NOT submitted or published or under consideration anywhere in other conferences or journals; in electronic format via email. 




Thanks Much 
Stefania Wilson
NEWS Division 
IRED
 If you no longer wish to receive mail from us, you can 
<http://tracking.theired.org/tracking/unsubscribe?msgid=ECwaXkqTQbHrnbVi-Pb8bQ2>
unsubscribe
IRED Headquarter, 42 Broadway, Suite 12-217, New York,
									NY 10004, USA
								
Tel: +1-(212) 901-3781
									|  Fax: +1-(212) 901-3786
								

[Message part 2 (text/html, inline)]

Message #299 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Stefania Wilson <stefania.wilson@theired.org>

To: 754513@bugs.debian.org

Subject: CFP - Thailand IRED Joint International Conference - August 2019

Date: Thu, 30 May 2019 21:37:59 +0000

[Message part 1 (text/plain, inline)]

Dear Friends,


We would like to invite you to submit research article in the 9th Joint International Conference organised by Institute of Research Engineers and Doctors at Bangkok, Thailand. The theme for the 2019 Thailand conference is to bring together innovative academics and industrial experts to a common forum. We would be delighted to have you present at this conference to hear what the technology experts and researchers have to share about the technology advancements and their impact on our daily lives.


Joint International Conference Consists of following tracks:



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ0kZOkA8zwmBw5059xFSw20ThG9jt-Esa-WV3LBJFGGKi-HVh4Mc4u92QN4L9cWS1aVLbgx9lussY2YMAM3g7mJHmmskT_F1VcuYYU8ol0Yx8w2>
Track 1: 9th International Conference on Advances in Computing, Electronics and Communication - ACEC

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ0kZOkA8zwmBw5059xFSw20ThG9jt-Esa-WV3LBJFGGKtWHPpxJgtwrdujs12xWoxHY81OT2CnHjx-ZvQABq1U_RddokaxIFfgne017QBYbAEw2>
Official Website: www.acec.theired.org



<http://tracking.theired.org/tracking/click?d=BWpoVaFv7Pbn0M65fQyf_XY3oA3MzLnKtXDQbwXQ5AxACEBvasZR6AMbnpHLumyZTfySRThkyd6UqobCp1lYetAooFQkllQUUr8qzPc9H02_ivWEdsxAtSNm6m6DuFTeDQ2>
Track 2: 9th International Conference On Advances in Civil, Structural and Environmental Engineering - ACSEE

<http://tracking.theired.org/tracking/click?d=BWpoVaFv7Pbn0M65fQyf_XY3oA3MzLnKtXDQbwXQ5AxACEBvasZR6AMbnpHLumyZxf0EqwuX0VRM3ClxylynqWKKYgGZuRibFtmIZ0r_Y8ldu1TFV5R8DPT2yhLNRRijpA2>
Official Website: www.acsee.theired.org



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ1EFCqSVXRKP8-d33R9Jfv9GM-s4KTe7oVlzcsmkZ_zomLFZCK5j-Zt6GpqhuPsYDqGmn8UFieRe1e_bJUaoFeZCBerJccZiaFcMIT0J_5wL2g2>
Track 3: 9th International Conference On Advances in Mechanical and Robotics Engineering - AMRE

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ1EFCqSVXRKP8-d33R9Jfv9GM-s4KTe7oVlzcsmkZ_zo17Nf26DBew__vvHIR87w2by-B06kCmO2HWB-WMqmI61sLGSdEc1fXm9D3CFygjtM2g2>
Official Website: www.amre.theired.org



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ6vygbBb3Xk_s1tXPjRxL-82Vcj9B77lnhYlHwg_-kq59xcchrTjOOeIDwx3VmOqxHkc_-Ofm_Nxp4nfOMNkyScKaiHgigHKIZnvg8Znqs2K8A2>
Track 4: 9th International Conference On Advances in Social Science, Management and Human Behaviour - SMHB

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ6vygbBb3Xk_s1tXPjRxL-82Vcj9B77lnhYlHwg_-kq5umyGPWJexbYsa3sIMIdnqlz4XT2OJFOowzeb9DFm90TK7TkMYdNOAw37nHZ_27cSbA2>
Official Website: www.smhb.theired.org


Conference Venue: Hotel Lebua at State Tower, Bangkok, Thailand


Conference Date: 03 - 04 August 2019


Abstract/ Full Paper Submission For Review: 10 June 2019




About Publication:

All the registered papers will proudly be published by IRED-CPS and stored in the SEEK digital Library 
<http://tracking.theired.org/tracking/click?d=1pvogq7UozbvCOeMr_RdFhcnr0XCagTCd8xvCHyt1vEE5ivnf8zoIdW3p4KqbSii1IOylWjisGXNnfPyZMYxYdWeUp_83JHubI0EkU37Peqj_5HFXwcZZbmQgE_ohC9E_Q2>
(www.seekdl.org). Each Paper will be assigned DOI (Digital Object Identifier) from CROSSREF. The Proc. will be submitted to ISI Thomson for Review and Indexing. Proc. will also be published in International Journals with ISSN Numbers.


Remote Presentation via Skype can also be arranged.


We would also like to share some conference photographs of previous held International conference that has been worldwide.


Kindly refer to the below link to access the conference photographs.

<http://tracking.theired.org/tracking/click?d=Yc8Niga1PEek6kjwbnvKhxolNzm1nz5ClcB7_yzWKsZffGm3ZdHBDUf2F7hYW03q3W6dOqqEb25XEOv4tBABX7IneClEvGgW59ZI6iAE1H6X9jjWAAeFZolbHnWQrZkpV9QnPhVQ9TZ-7EA7EeHnECc1>

<http://tracking.theired.org/tracking/click?d=1pvogq7UozbvCOeMr_RdFsMnj-CAjt3iR8vsZa-g7Qe8JKBZcPk_Xb24L2y1wgXnNoNZhuJ-gHSBB1J3xqrX_byK5odi8A_gAp_YqmRBZRGTYMhCocE-Aci906tE6lReBw2>
https://gallery.theired.org/previous-conferences/



We Request you to forward this email to your colleagues/Researchers/students in order to promote the conference.


The aim of the conference is to provide a platform to the researchers and practitioners from both academia as well as industry to meet and share cutting-edge development in the field.
Please take the time to explore the website for more details, check on important dates, and keep yourself up to date on recent changes. 



Registered Papers (IRED Extended paper guidelines applicable) will be published in the various issues of International journals.
Prospective authors are invited to submit full (original) research papers; which are NOT submitted or published or under consideration anywhere in other conferences or journals; in electronic format via email. 




Thanks Much 
Stefania Wilson
NEWS Division 
IRED
 If you no longer wish to receive mail from us, you can 
<http://tracking.theired.org/tracking/unsubscribe?msgid=EoR3JFOZXgf-4IoyVK_xYg2>
unsubscribe
IRED Headquarter, 42 Broadway, Suite 12-217, New York,
									NY 10004, USA
								
Tel: +1-(212) 901-3781
									|  Fax: +1-(212) 901-3786
								

[Message part 2 (text/html, inline)]

Message #304 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Stefania Wilson <stefania.wilson@theired.org>

To: 754513@bugs.debian.org

Subject: CFP- International Conference @ University of Westminster, London, UK

Date: Fri, 14 Jun 2019 20:06:46 +0000

[Message part 1 (text/plain, inline)]

Dear Friends,


We would like to invite you to submit research article in the 9th Joint International Conference organised by Institute of Research Engineers and Doctors at University of Westminster, London, UK. The theme for the 2019 UK conference is to bring together innovative academics and industrial experts to a common forum. We would be delighted to have you present at this conference to hear what the technology experts and researchers have to share about the technology advancements and their impact on our daily lives.


Joint International Conference Consists of following tracks:



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJyU_aMDrx6JCbEXXFdsmgXPfyIasenPV8AgOqoKGAtDJfA6kyNhK_Rpn2wnwPqO73MCR5Of-lELOpo4ntA8F7B_TUysEukgGnvPRWspzdmQWDg2>
Track 1: 9th International Conference on Advances in Computing, Control and Networking - ACCN

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJyU_aMDrx6JCbEXXFdsmgXPfyIasenPV8AgOqoKGAtDJHhG47RpnO-bEOoTLdkUwe1wTjuEAE2f5KGiW4POWu6IcyrngJjV2ecQ6Dr1cljhifg2>
Official Webiste: www.accn.theired.org



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ-66gin6ghmi_nTQ8RWvRbj7iOy-L3pJzbJDoax_f_TIoT_BLRyaUB6hr4RL95uy7zjcwHcs8WNzKR0HfTHJ823nzFz8cRo0bgTJKURiT2h3Zg2>
Track 2: 9th International Conference On Advances in Civil, Structural and Mechanical Engineering - ACSM

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ-66gin6ghmi_nTQ8RWvRbj7iOy-L3pJzbJDoax_f_TIoi77SxETGY3Sgi38w_OAQG-FPgWPzQv0k6fTqjswf3McshKCHs0hGdQj6pPcGz9VvQ2>
Official Webiste: www.acsm.theired.org



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ79lbEBkJHofgsE-G4EmRkpSB29kGS9y1elDXIsWhbQkFCVPDHJxVKEUagOHGoH5nnE1S4PtMm2Lb1QpkIeN9Q0I0ZHnVpaSvMI6HE6NDtKB_w2>
Track 3: 9th International Conference On Advances in Applied Science and Environmental Technology - ASET

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ79lbEBkJHofgsE-G4EmRkpSB29kGS9y1elDXIsWhbQkSIRuIDW2-BzDySogUfe4sq6Mu7Il6dq2e0iCLq4nr2e5vX0jAOWoiRdQ6iGo4brVlw2>
Official Webiste: www.aset.theired.org



<http://tracking.theired.org/tracking/click?d=QM81x6k1RxgNs031BT7L67rYPp4ChBKmPGLUl-R67pMFMM6a6uAPA765RXnt-p6xcfAg-VHJT861W07w2HOIOsah_8r1RB5tLImPpTBjgP4YB0B6eGGVUuDKvwqF_DwEgg2>
Track 4: 9th International Conference On Advances in Economics, Social Science and Human Behaviour Study - ESSHBS​
<http://tracking.theired.org/tracking/click?d=9z9hOpXCgxLxIZYyyr-71J7OaA-h7vIfrRdr87efQLirrZ5KQAnILygugpgKylFK1WnF5RGjU7L1z12GHD_ud_GG-FhJC9DYyV4plKVaiYXoP2GX4os8PH9EYu8t1rPFUA2>


<http://tracking.theired.org/tracking/click?d=QM81x6k1RxgNs031BT7L67rYPp4ChBKmPGLUl-R67pMFMM6a6uAPA765RXnt-p6x6eAUs1jsRy6tsQexve4TlUSyiPsjbsDXoLcDK6m2pXQWeEH8I-WucWvwH4JS7VF1_g2>
Official Webiste: www.esshbs.theired.org​




Conference Venue: University of Westminster, London, UK


Conference Date: 20 - 21 July 2019


Abstract/ Full Paper Submission in Final Round For Review: 23 June 2019


*Paper Acceptance will be sent on or before: 26 June 2019





About University of Westminster (Conference Venue):
--The University of Westminster is a public university in London, United Kingdom. Its antecedent institution, the Royal Polytechnic Institution, was founded in 1838 and was the first polytechnic institution in the UK. Westminster was awarded university status in 1992 meaning it could award its own degrees.


--Its headquarters and original campus are in Regent Street in the City of Westminster area of central London, with additional campuses in Fitzrovia, Marylebone and Harrow. It operates the Westminster International University in Tashkent in Uzbekistan.


--Westminster's academic activities are organised into seven faculties and schools, within which there are around 45 departments. The University has numerous centres of research excellence across all the faculties, including the Communication and Media Research Institute, whose research is ranked in the Global Top 40 by the QS World University Rankings. Westminster had an income of £170.4 million in 2012/13, of which £4.5 million was from research grants and contracts.


--Westminster is a member of the Association of Commonwealth Universities, the Association of MBAs, EFMD, the European University Association and Universities UK.


About Publication:​

All the registered papers will proudly be published by IRED-CPS and stored in the SEEK digital Library 
<http://tracking.theired.org/tracking/click?d=1pvogq7UozbvCOeMr_RdFhcnr0XCagTCd8xvCHyt1vGRhUP6MeRTC4YcMUnN5zMTJZGT_PtHlg-68ngWG41hd--0QcM25r-ge3mmLH0ZqjC-Oymdnedjojp81e2picsIYw2>
(www.seekdl.org). Each Paper will be assigned DOI (Digital Object Identifier) from CROSSREF. The Proc. will be submitted to ISI Thomson for Review and Indexing. Proc. will also be published in International Journals with ISSN Numbers.


Remote Presentation via Skype can also be arranged.


We would also like to share some conference photographs of previous held International conference that has been worldwide.


Kindly refer to the below link to access the conference photographs.

<http://tracking.theired.org/tracking/click?d=Yc8Niga1PEek6kjwbnvKhxolNzm1nz5ClcB7_yzWKsZffGm3ZdHBDUf2F7hYW03qcpVaja61WPPxUidWVj5UyXxiHJf5Hllic6nWyEIiHwkWpI1VUlpKmQWe4XR1w-oXS5GQxvo5l8_or_nJ4dE7DW41>

<http://tracking.theired.org/tracking/click?d=1pvogq7UozbvCOeMr_RdFsMnj-CAjt3iR8vsZa-g7QdsqsMnZHVm3PICi3JJcNStjAoFNvw4XMFX5K8vsZjV40D5VwwBZV1YmYUtg_OhWiPPu9sWcfgRSjfPt8Hzhg26lw2>
https://gallery.theired.org/previous-conferences/



We Request you to forward this email to your colleagues/Researchers/students in order to promote the conference.


The aim of the conference is to provide a platform to the researchers and practitioners from both academia as well as industry to meet and share cutting-edge development in the field.
Please take the time to explore the website for more details, check on important dates, and keep yourself up to date on recent changes. 



Registered Papers (IRED Extended paper guidelines applicable) will be published in the various issues of International journals.
Prospective authors are invited to submit full (original) research papers; which are NOT submitted or published or under consideration anywhere in other conferences or journals; in electronic format via email. 




Thanks Much 
Stefania Wilson
NEWS Division 
IRED
 If you no longer wish to receive mail from us, you can 
<http://tracking.theired.org/tracking/unsubscribe?msgid=i-nYmNS6M4Wq9_HeQVz7bg2>
unsubscribe
IRED Headquarter, 42 Broadway, Suite 12-217, New York,
									NY 10004, USA
								
Tel: +1-(212) 901-3781
									|  Fax: +1-(212) 901-3786
								

[Message part 2 (text/html, inline)]

Message #309 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Stefania Wilson <stefania.wilson@theired.org>

To: 754513@bugs.debian.org

Subject: Last Change Paper Submission - International Conference @ University of Westminster, London, UK

Date: Tue, 18 Jun 2019 19:38:59 +0000

[Message part 1 (text/plain, inline)]

Dear Friends,


We would like to invite you to submit research article in the 9th Joint International Conference organised by Institute of Research Engineers and Doctors at University of Westminster, London, UK. The theme for the 2019 UK conference is to bring together innovative academics and industrial experts to a common forum. We would be delighted to have you present at this conference to hear what the technology experts and researchers have to share about the technology advancements and their impact on our daily lives.


Joint International Conference Consists of following tracks:



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJyU_aMDrx6JCbEXXFdsmgXOTWbQ1KHpiDQjTkb3ZdG28aDs7aKikBClet5XZxgYE_quBvH96JbmUSfILir_X1KJhNagyUFf4jNOgzoDP6hklIw2>
Track 1: 9th International Conference on Advances in Computing, Control and Networking - ACCN

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJyU_aMDrx6JCbEXXFdsmgXOTWbQ1KHpiDQjTkb3ZdG28dSVVjgo-ZcD6DQH0UfgqYbhjeBdMuT-QKtdbdPRphXAlkJv67cLMBnRcWxfSlublKw2>
Official Webiste: www.accn.theired.org



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ-66gin6ghmi_nTQ8RWvRbioC6oS8Une77mY5pYTqurjl0KUNbhZ-uF8_ewPRG5-QgD-9QXGnWKqe24qoPQH5qxBBh0kcEYt49EIri29ah0IDA2>
Track 2: 9th International Conference On Advances in Civil, Structural and Mechanical Engineering - ACSM

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ-66gin6ghmi_nTQ8RWvRbioC6oS8Une77mY5pYTqurjEUTP2DfuV-7Tt35fZmlFEgGk2ZCO4J_HV0VuIqfDa4zJpo2dX9M4pVDvAFF0L1bG_A2>
Official Webiste: www.acsm.theired.org



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ79lbEBkJHofgsE-G4EmRkrIU8SJUNAng43Auv9GpPBjWXEXJ72k7W6DePjA28NLoX9SZcJWMzxDR2B9PgkNXNzdp4g6x2k_YQHWjfM9W53Dpw2>
Track 3: 9th International Conference On Advances in Applied Science and Environmental Technology - ASET

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ79lbEBkJHofgsE-G4EmRkrIU8SJUNAng43Auv9GpPBj2myW50um50xyfmvqzXAPnsphsBk3vZH2vSAAdgGJRmE6vY-EVq9ELds-p3Smi8QxdA2>
Official Webiste: www.aset.theired.org



<http://tracking.theired.org/tracking/click?d=QM81x6k1RxgNs031BT7L67rYPp4ChBKmPGLUl-R67pMJ9yc-Lvak-GbRdewPvJOrwS9XnWRrQv-vcJjp-nx3uNe3uS5nPv9IM72LJbkcnad6qzM3szPGvN1UJ6dgUL_KHw2>
Track 4: 9th International Conference On Advances in Economics, Social Science and Human Behaviour Study - ESSHBS​
<http://tracking.theired.org/tracking/click?d=9z9hOpXCgxLxIZYyyr-71J7OaA-h7vIfrRdr87efQLiDnWgqQAGjtkUDIsgwPdxnSWOVc4k1Aew1ig162d7QaqzKtgxIeTtsi7go6xW1KEDKPu-QKOvrLZoiHCKuPdQXEA2>


<http://tracking.theired.org/tracking/click?d=QM81x6k1RxgNs031BT7L67rYPp4ChBKmPGLUl-R67pMJ9yc-Lvak-GbRdewPvJOrpsgDbOzRKB3Dx2PGO6f7yqnBEUcGmUVVMpAu4fh8I8NIYc1ZQN56-vRwOYjrIu7saQ2>
Official Webiste: www.esshbs.theired.org​




Conference Venue: University of Westminster, London, UK


Conference Date: 20 - 21 July 2019


Abstract/ Full Paper Submission in Final Round For Review: 23 June 2019


*Paper Acceptance will be sent on or before: 26 June 2019





About University of Westminster (Conference Venue):
--The University of Westminster is a public university in London, United Kingdom. Its antecedent institution, the Royal Polytechnic Institution, was founded in 1838 and was the first polytechnic institution in the UK. Westminster was awarded university status in 1992 meaning it could award its own degrees.


--Its headquarters and original campus are in Regent Street in the City of Westminster area of central London, with additional campuses in Fitzrovia, Marylebone and Harrow. It operates the Westminster International University in Tashkent in Uzbekistan.


--Westminster's academic activities are organised into seven faculties and schools, within which there are around 45 departments. The University has numerous centres of research excellence across all the faculties, including the Communication and Media Research Institute, whose research is ranked in the Global Top 40 by the QS World University Rankings. Westminster had an income of £170.4 million in 2012/13, of which £4.5 million was from research grants and contracts.


--Westminster is a member of the Association of Commonwealth Universities, the Association of MBAs, EFMD, the European University Association and Universities UK.


About Publication:​

All the registered papers will proudly be published by IRED-CPS and stored in the SEEK digital Library 
<http://tracking.theired.org/tracking/click?d=1pvogq7UozbvCOeMr_RdFn0uAU0bmpabPhTxjfyDz3ln2zgtyHpvmls90tQKfqEKQsE7MNEp1YiMOa6h-Bzxh2VefdT69Npuk3PumD6IeRVv_61M_w5qW4O6kpQnp_WVEg2>
(www.seekdl.org). Each Paper will be assigned DOI (Digital Object Identifier) from CROSSREF. The Proc. will be submitted to ISI Thomson for Review and Indexing. Proc. will also be published in International Journals with ISSN Numbers.


Remote Presentation via Skype can also be arranged.


We would also like to share some conference photographs of previous held International conference that has been worldwide.


Kindly refer to the below link to access the conference photographs.

<http://tracking.theired.org/tracking/click?d=Yc8Niga1PEek6kjwbnvKhxolNzm1nz5ClcB7_yzWKsZffGm3ZdHBDUf2F7hYW03qdnyZgDVN8j5D22InyxqjJ4xnMEqn8XPMMTyozcNVHbgfyXCyh6eZ1rWmnqbADVnNjjMbYIoNfVaLiKGQ3eBixmw1>

<http://tracking.theired.org/tracking/click?d=1pvogq7UozbvCOeMr_RdFnCxZSpW06syO3KWtG8jD8u2SmagczjX7axnuiE3DQxuu4hNMAz9GTAzB5zNy0ob2daMe5I8U6N5ACyY23DqC06RqvSCCBDA9aKCHmaIzF7SxA2>
https://gallery.theired.org/previous-conferences/



We Request you to forward this email to your colleagues/Researchers/students in order to promote the conference.


The aim of the conference is to provide a platform to the researchers and practitioners from both academia as well as industry to meet and share cutting-edge development in the field.
Please take the time to explore the website for more details, check on important dates, and keep yourself up to date on recent changes. 



Registered Papers (IRED Extended paper guidelines applicable) will be published in the various issues of International journals.
Prospective authors are invited to submit full (original) research papers; which are NOT submitted or published or under consideration anywhere in other conferences or journals; in electronic format via email. 




Thanks Much 
Stefania Wilson
NEWS Division 
IRED
 If you no longer wish to receive mail from us, you can 
<http://tracking.theired.org/tracking/unsubscribe?msgid=-LRIyMtZ1KByiPvaxluprw2>
unsubscribe
IRED Headquarter, 42 Broadway, Suite 12-217, New York,
									NY 10004, USA
								
Tel: +1-(212) 901-3781
									|  Fax: +1-(212) 901-3786
								

[Message part 2 (text/html, inline)]

Message #314 received at 754513@bugs.debian.org (full text, mbox, reply):

From: Stefania Wilson <stefania.wilson@theired.org>

To: 754513@bugs.debian.org

Subject: CFP - Thailand International Conference - July 2019

Date: Tue, 25 Jun 2019 22:43:00 +0000

[Message part 1 (text/plain, inline)]

<http://tracking.theired.org/tracking/click?d=q7ffcc3hdKlkh3Viyt4MhrOzEX29Gn1I0EpiqssyNsPM0YzC7pq0kqJa1uFvuM_sBb1kpWzRZj8VVZbcc_t7phGeOLD0dqoIiBlzNHaVB5Dh1OtzQpHtl--4CBUEA9id0g2>

Dear Friends,


We would like to invite you to submit research article in the 9th Joint International Conference organised by Institute of Research Engineers and Doctors at Bangkok, Thailand. The theme for the 2019 Thailand conference is to bring together innovative academics and industrial experts to a common forum. We would be delighted to have you present at this conference to hear what the technology experts and researchers have to share about the technology advancements and their impact on our daily lives.


Joint International Conference Consists of following tracks:



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ0kZOkA8zwmBw5059xFSw21sF6y_jIRl_AWlALcMrOjy2BZvzSdSrbPA1VmTXNiBfCwqTL-NHbVh-pQd9tIaKkUWuUBVruqI_7_YDBwFQaag3g2>
Track 1: 9th International Conference on Advances in Computing, Electronics and Communication - ACEC

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ0kZOkA8zwmBw5059xFSw21sF6y_jIRl_AWlALcMrOjyY33Itq5iufAzRcM-oD0kAPat-5qAVoKgORof5bwGqu2IyyEaZU_nj50sU6D1pbuQCA2>
Official Website: www.acec.theired.org



<http://tracking.theired.org/tracking/click?d=BWpoVaFv7Pbn0M65fQyf_XY3oA3MzLnKtXDQbwXQ5AwFM7lGR5dIVN-BWxsm9a9_mDQOgoCSARt77NLTxpOQ_xkr7LPEn0T5d9-OMpOI2YrtZfLwo4NYIDpMro3c6b7zjQ2>
Track 2: 9th International Conference On Advances in Civil, Structural and Environmental Engineering - ACSEE

<http://tracking.theired.org/tracking/click?d=BWpoVaFv7Pbn0M65fQyf_XY3oA3MzLnKtXDQbwXQ5AwFM7lGR5dIVN-BWxsm9a9_bn-nxjn7e2qRfxrkiYe6ZA1Q_VL_bWpdb1au_bKLpU1FAr2p-3kqWvzQgUVfyUcu8A2>
Official Website: www.acsee.theired.org



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ1EFCqSVXRKP8-d33R9Jfv86XgLwtEVCS98bzyGs8XgmZ-Y7k63C60rkC64QHZ__RFAVhuhZsZBCSdxACu0-aNpjI_cShyhj4oc2930a3U0TOA2>
Track 3: 9th International Conference On Advances in Mechanical and Robotics Engineering - AMRE

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ1EFCqSVXRKP8-d33R9Jfv86XgLwtEVCS98bzyGs8XgmXrQWb7hmbyDkaBsU-mhm3nrTpzP52YptszWIXmuZDnECLesJh2pn6DqhAN45_PgLMQ2>
Official Website: www.amre.theired.org



<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ6vygbBb3Xk_s1tXPjRxL-8Vp2rhlYc7pfzyNCwQR2jHLuNRXnCFJlVdFtddd1YInwV28elQob7ZUeDFhWlePKSE7qhREi5oNyZPbbpRS2-cKg2>
Track 4: 9th International Conference On Advances in Social Science, Management and Human Behaviour - SMHB

<http://tracking.theired.org/tracking/click?d=IEK2eAAWLBWf6oUPKZVvJ6vygbBb3Xk_s1tXPjRxL-8Vp2rhlYc7pfzyNCwQR2jH46WXTcBzQiRosO4xsgt4GNKsrRGYKogb66eget-zdrWUC-lQH4e-S2Hyhva-K_kYNg2>
Official Website: www.smhb.theired.org


Conference Venue: Hotel Lebua at State Tower, Bangkok, Thailand


Conference Date: 13 - 14 September 2019


Abstract/ Full Paper Submission For Review: 14 July 2019




About Publication:

All the registered papers will proudly be published by IRED-CPS and stored in the SEEK digital Library 
<http://tracking.theired.org/tracking/click?d=1pvogq7UozbvCOeMr_RdFn0uAU0bmpabPhTxjfyDz3lajy_v3ROk4ifJuU-3pDMP2o1GCWiCuOIl6pki4CVGNRa5MpCGtkPrI8PHePLQpO9dwYVfozGJokC5uYp74pxx3g2>
(www.seekdl.org). Each Paper will be assigned DOI (Digital Object Identifier) from CROSSREF. The Proc. will be submitted to ISI Thomson for Review and Indexing. Proc. will also be published in International Journals with ISSN Numbers.


Remote Presentation via Skype can also be arranged.


We would also like to share some conference photographs of previous held International conference that has been worldwide.


Kindly refer to the below link to access the conference photographs.

<http://tracking.theired.org/tracking/click?d=Yc8Niga1PEek6kjwbnvKhxolNzm1nz5ClcB7_yzWKsZffGm3ZdHBDUf2F7hYW03qj-2z4LTXD4QGQZ0TU5Ypmrlxl3dCxHrbYg3fhoAe6p5HY4Gz0CuccIxgUyGoyOaCg0aqYPCbx4g2vz50I02c5_81>

<http://tracking.theired.org/tracking/click?d=1pvogq7UozbvCOeMr_RdFnCxZSpW06syO3KWtG8jD8vnfBDOP-_ttoW8qervgdZzMVSZmK7BbY2HFUR75wAbKBDD2nWnuMbPupxlKDScRF2MK5RkRBQ1AhEvO7IbFdvn2Q2>
https://gallery.theired.org/previous-conferences/



We Request you to forward this email to your colleagues/Researchers/students in order to promote the conference.


The aim of the conference is to provide a platform to the researchers and practitioners from both academia as well as industry to meet and share cutting-edge development in the field.
Please take the time to explore the website for more details, check on important dates, and keep yourself up to date on recent changes. 



Registered Papers (IRED Extended paper guidelines applicable) will be published in the various issues of International journals.
Prospective authors are invited to submit full (original) research papers; which are NOT submitted or published or under consideration anywhere in other conferences or journals; in electronic format via email. 




Thanks Much 
Stefania Wilson
NEWS Division 
IRED
 If you no longer wish to receive mail from us, you can 
<http://tracking.theired.org/tracking/unsubscribe?msgid=H6HmVbLq6QABvmmKoEv2Lg2>
unsubscribe
IRED Headquarter, 42 Broadway, Suite 12-217, New York,
									NY 10004, USA
								
Tel: +1-(212) 901-3781
									|  Fax: +1-(212) 901-3786
								

[Message part 2 (text/html, inline)]

Send a report that this bug log contains spam.