Re: F26 System Wide Change: OpenSSL 1.1.0

[David Woodhouse]

On Thu, 2016-09-29 at 17:02 +, Ralf Senderek wrote:
> 
> > What we should strive for is to limit the use of crypto to one of these 
> > three libraries and avoid any additional ones with exception of 
> > libgcrypt for gnupg2.
> 
> This assumption ignores the fact that Cryptlib has joined Fedora and has 
> every right to be included in that list.

And don't forget Botan. I just rebuilt SoftHSM against that here,
because I got tired of having muiltiple versions of OpenSSL in the same
process

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[David Woodhouse]

On Wed, 2016-09-28 at 11:43 -0400, Matthew Miller wrote:
> 
>   The libraries that should be preferred instead of arbitrary other
>   crypto stacks are (in the order of the preference):
> 
>   1. NSS
>   2. GNUTLS (with nettle as crypto backend, but nettle never used
>    directly by applications)
>   3. OpenSSL
>   4. libgcrypt 
> 
> and it might be reasonable to keep this as a "if possible, please
> prefer" policy rather than a mandate.

That is out of date. NSS should not be at the top now, for Fedora.

Our packaging guidelines¹ say that packages SHOULD work seamlessly with
PKCS#11 — if I plug in my Yubikey, or if I want to use a cert from
SoftHSM or GNOME keyring or something like that, then I should just be
able to use a standard PKCS#11 URI like 

  'pkcs11:manufacturer=piv_II;id=%01'

Applications should automatically accept an identifier like that in
place of a filename, whenever they can use certs from a file.

With GnuTLS and OpenSSL, this works fine (OpenSSL apps need to use the
ENGINE but it's relatively simple). With NSS... it's broken. Bugs² have
been filed upstream... patches have even been attached to those bugs.
But it looks like with Fedora 25, YET ANOTHER Fedora release is going
out the door without NSS getting fixed.

There are bugs open against packages like curl which would be *fixed*
by moving them away from NSS and onto something else. Anything else.


I strongly suspect that any historical anecdotal bugs about switching
crypto libraries are irrelevant now. All three major crypto libraries
now conform to the same system policy about which versions of TLS to
use and which ciphers to enable — which was the most likely reason for
any sudden change in interoperability in the past. But without bug
numbers, any such anecdotes were immediately discardable anyway, of
course.

-- 
dwmw2

¹ https://fedoraproject.org/wiki/Packaging:SSLCertificateHandling
² https://bugzil.la/1296263 and https://bugzil.la/1162897


smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[Ralf Senderek]

Tomas Mraz wrote:
> My personal recommendation would be to follow the application's upstream 
> recommendation.

This is of course the best approach, as the upstream project will have good 
reasons to use a particular crypto foundation for the project.

> What we should strive for is to limit the use of crypto to one of these 
> three libraries and avoid any additional ones with exception of 
> libgcrypt for gnupg2.

This assumption ignores the fact that Cryptlib has joined Fedora and has 
every right to be included in that list.

https://admin.fedoraproject.org/pkgdb/package/rpms/cryptlib/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[Graham Leggett]

On 29 Sep 2016, at 08:51, Nikos Mavrogiannopoulos  wrote:

> I'd like to underline the part _preferrably the version recommended by
> upstream_ of Packaging:CryptoPolicies. I believe it is best for us to
> use the code that upstream primarily considers best for the
> application.

+1.

Regards,
Graham
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[Nikos Mavrogiannopoulos]

On Wed, 2016-09-28 at 11:43 -0400, Matthew Miller wrote:
> On Wed, Sep 28, 2016 at 03:13:34PM +0100, Tomasz Kłoczko wrote:
> > 
> > Is it any official Fedora policy/call to move away from openssl?
> 
> As far as I know, no. There was this attempt:
> https://fedoraproject.org/wiki/FedoraCryptoConsolidation
> but as the top of the page notes, the effort has been abandoned.
> (It's
> basically impossible to change every project in the world.) From that
> document, though:
> 
>   The libraries that should be preferred instead of arbitrary other
>   crypto stacks are (in the order of the preference):
> 
>   1. NSS
>   2. GNUTLS (with nettle as crypto backend, but nettle never used
>    directly by applications)
>   3. OpenSSL
>   4. libgcrypt 
> and it might be reasonable to keep this as a "if possible, please
> prefer" policy rather than a mandate.

I'd like to underline the part _preferrably the version recommended by
upstream_ of Packaging:CryptoPolicies. I believe it is best for us to
use the code that upstream primarily considers best for the
application.

regards,
Nikos

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[Tomas Mraz]

On 28.9.2016 16:13, Tomasz Kłoczko wrote:

BTW openssl changes.

Is it any official Fedora policy/call to move away from openssl?
I'm asking because I've noticed that some packages seems have been
switched from openssl to gnutls.
Examples of those packages is wget:
* Tue Jul 26 2016 Tomas Hozza mailto:tho...@redhat.com>> - 1.18-2
- Switched openssl to gnutls for crypto

Another package example which is is linked with gntls instead with
openssl is lftp.

A the moment in Fedora is possible to use three types of SSL/crypto
libraries: gnutls, openssl and nss.
Short test on my system:

$ for i in nss gnutls openssl-libs; do echo -n "$i ";  rpm -e $i 2>&1 |
awk '{print $6}' | grep -v ^$i | sort | uniq | wc -l; done
nss 57
gnutls 33
openssl-libs 110



I do not think we are going to drop any of these three tls/crypto 
libraries from Fedora (and RHEL) in foreseeable future. So there is no 
point in forcibly switching applications to particular one.


My personal recommendation would be to follow the application's upstream 
recommendation.


What we should strive for is to limit the use of crypto to one of these 
three libraries and avoid any additional ones with exception of 
libgcrypt for gnupg2.


Tomas Mraz
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[Tomasz Kłoczko]

> 1. NSS
>  2. GNUTLS (with nettle as crypto backend, but nettle never used
>   directly by applications)
>  3. OpenSSL
>  4. libgcrypt
>
> and it might be reasonable to keep this as a "if possible, please prefer"
policy rather than a mandate.

Seems preferring gnutls over openssl is creating problems which I've
described. Really until more packages (kind of critical mass) will have
possibility to switch to other TLS/crypto libraries better IMO would be
stick with openssl. In  mean time for example possibility switching to
other one IMO should be kept as %bcond,
Is it any reason why openssl is below gnutls. I know that openssl has bad
reputation but exactly this reputation caused that in last 2-3 years more
eyes have been looking on openssl than gnutls and IMO only by this using
gnutls is more risky.

On the web page with list of packages moved to use nss is curl.
I found that dist package binaries are using now nss and openssl.
Quick test with add in %configure parameters in curl.spec modification
like:

-%configure --disable-static \
+%configure \
+LDFLAGS="-Wl,--as-needed" \
+--disable-static \
 --enable-symbol-hiding \

solves problem. With above and without ldd output is the same but on elf
NEEDED list is much less libraries:

[tkloczko@domek .libs]$ objdump -x /usr/bin/curl | grep NEEDED
  NEEDED   libcurl.so.4
  NEEDED   libmetalink.so.3
  NEEDED   libssl3.so
  NEEDED   libsmime3.so
  NEEDED   libnss3.so
  NEEDED   libnssutil3.so
  NEEDED   libplds4.so
  NEEDED   libplc4.so
  NEEDED   libnspr4.so
  NEEDED   libpthread.so.0
  NEEDED   libdl.so.2
  NEEDED   libz.so.1
  NEEDED   libc.so.6
[tkloczko@domek .libs]$ objdump -x curl | grep NEEDED
  NEEDED   libcurl.so.4
  NEEDED   libmetalink.so.3
  NEEDED   libnss3.so
  NEEDED   libplds4.so
  NEEDED   libnspr4.so
  NEEDED   libpthread.so.0
  NEEDED   libz.so.1
  NEEDED   libc.so.6

Result is that in case of any changes around openssl curl will be not
affected (does not need to be rebuild).
-Wl,--as-needed removes from rpm dependencies few other packages.

Anyone may have something against pushing to git change with above?

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[Matthew Miller]

On Wed, Sep 28, 2016 at 03:13:34PM +0100, Tomasz Kłoczko wrote:
> Is it any official Fedora policy/call to move away from openssl?

As far as I know, no. There was this attempt:
https://fedoraproject.org/wiki/FedoraCryptoConsolidation
but as the top of the page notes, the effort has been abandoned. (It's
basically impossible to change every project in the world.) From that
document, though:

  The libraries that should be preferred instead of arbitrary other
  crypto stacks are (in the order of the preference):

  1. NSS
  2. GNUTLS (with nettle as crypto backend, but nettle never used
   directly by applications)
  3. OpenSSL
  4. libgcrypt 

and it might be reasonable to keep this as a "if possible, please
prefer" policy rather than a mandate.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[Graham Leggett]

On 28 Sep 2016, at 4:13 PM, Tomasz Kłoczko  wrote:

> BTW openssl changes.

> It would be good to form kind of official guidline about using those 
> alternative libraries and start pushing to use only one.

This is not always possible.

I spent a long time debugging 389ds on Ubuntu because someone had arbitrarily 
decided to switch the LDAP client library from NSS to gnutls. This in turn 
broke 389ds server replication, which embeds both the server code (depending on 
NSS) and client code (depending on gnutls) into the same code and then trying 
to use the same configuration for both of them. Our solution was to switch to 
CentOS.

Regards,
Graham
—
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[Emmanuel Seyman]

* Tomasz Kłoczko [28/09/2016 15:13] :
>
> Is it any official Fedora policy/call to move away from openssl?

We had plans to that effect a while back :
http://fedoraproject.org/wiki/FedoraCryptoConsolidation

Emmanuel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[Tomasz Kłoczko]

BTW openssl changes.

Is it any official Fedora policy/call to move away from openssl?
I'm asking because I've noticed that some packages seems have been switched
from openssl to gnutls.
Examples of those packages is wget:
* Tue Jul 26 2016 Tomas Hozza  - 1.18-2
- Switched openssl to gnutls for crypto

Another package example which is is linked with gntls instead with openssl
is lftp.

A the moment in Fedora is possible to use three types of SSL/crypto
libraries: gnutls, openssl and nss.
Short test on my system:

$ for i in nss gnutls openssl-libs; do echo -n "$i ";  rpm -e $i 2>&1 | awk
'{print $6}' | grep -v ^$i | sort | uniq | wc -l; done
nss 57
gnutls 33
openssl-libs 110

Result is that some applications on runtime are loading more than one of
those libraries.
It would be good to form kind of official guidline about using those
alternative libraries and start pushing to use only one.
In most of the cases is possible to choose between use openssl and gnutls
on compile time. In case some packages some people prepared patches
allowing to choose openssl instead gnutls.

Very similar situation is with expat vis libxml2. Biggest problem is with
fontconfig which is used by few widely used packages used on desktop.
Almost all GNOME source code is only developed to use libxml2 however using
by those software fontconfig is causing that both xml parsing libraries are
loaded into memory on runtime.
It is very good reason to choose libxml2 over expat which is lower memory
consumption and some benchmarks shows that libxml2 is faster than expat.
Again some sample from my system:

$ for i in expat libxml2; do echo -n "$i ";  rpm -e $i 2>&1 | awk '{print
$6}' | grep -v ^$i | sort | uniq | wc -l; done
expat 49
libxml2 144

This duality is causing loading both libraries in case for example apache
web server with loaded php and xml php extension. Apache is using expat and
php is using libxml2. Apache is especially messy because even in his own
source tree some modules are/can using libxml2 and other only expat.

IMO where never is now possible to choose between expat and libxml2 IMO
officially libxml2 should be used.
Actually in case of fontconfig switching to use libxml2 is very easy.All
what needs to be done is add --enable-libxml2 --without-expat to configure
options and switch in BuildRequires from expat-devel to libxml2-devel, bump
release and push to rebuild package.

kloczek
-- 
Tomasz Kłoczko |  LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[Tomas Mraz]

On Út, 2016-09-27 at 03:36 +1000, Timothy Ward wrote:
> HHello
> 
> Has there been any testing with libmobiledevice library and
> especially
> the gvfs-afc backend to this be able to connect to an idevice using
> nautilus etc. The testing needs to be done on both new IOS 10.0.1
> and an older version say 6.3.5 on an older idevice iphone 4. to
> ensure
> compatibility across 
> 
> A link to a github respository for libimobledevice and other related
> libaries 
> 
> https://github.com/libimobiledevice
> 
> Have a look at the issues for problems with openssl etc

I am sorry but I certainly cannot promise to test all dependent
packages with the new OpenSSL - that's out question. The testing has to
be done by the respective package maintainers and the package users as
for all other cases of library package updates.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[Timothy Ward]

HHello

Has there been any testing with libmobiledevice library and especially
the gvfs-afc backend to this be able to connect to an idevice using
nautilus etc. The testing needs to be done on both new IOS 10.0.1
and an older version say 6.3.5 on an older idevice iphone 4. to ensure
compatibility across 

A link to a github respository for libimobledevice and other related
libaries 

https://github.com/libimobiledevice

Have a look at the issues for problems with openssl etc

Regards

Timothy Ward


On Mon, 2016-09-26 at 10:09 +0200, Tomas Mraz wrote:
> 
> On So, 2016-09-24 at 00:52 +0100, David Woodhouse wrote:
> > 
> > 
> > On Tue, 2016-09-20 at 11:37 +0200, Tomas Mraz wrote:
> > > 
> > > 
> > > 
> > > Well... we certainly need to port it sooner or later although I
> > > understand that effort will be quite non-trivial.
> > You mean port libp11? That's already working against OpenSSL 1.1,
> > isn't
> > it? We just need to ensure we can ship a version of libp11 — or at
> > least the engine — for both OpenSSL 1.1 and OpenSSL 1.0.2, if
> > we're
> > going to ship them both in parallel.
> 
> Ah, that's a good news. I did not get to try to rebuild it against
> OpenSSL1.1 yet.
> 
> My current plan is to not ship such engine-pkcs11 package. We should
> try to move everything to OpenSSL 1.1 and ship the 1.0.2 only as a
> compat package for third party binaries without -devel and any extra
> bells and whistles. It would be also temporarily used in Rawhide so
> it
> is installable but for that I think we can live with temporarily
> breaking PKCS#11 uri support.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[David Woodhouse]

On Mon, 2016-09-26 at 12:29 +0200, Tomas Mraz wrote:
> My current plan is to just switch and rebuild fixing the FTBFS during
> that. I want to persuade some of my colleagues to help me with that
> (and of course community help is also welcome).
> 
> Also we will be sharing the work with other downstream distributions
> here:
> https://github.com/patch-exchange/openssl-1.1-transition

Hm... might I suggest that every patch in there be tagged with an
'upstream status', and a link to the mailing list archive or ticket or
pull request where it was submitted upstream?

For which, the patches would actually need to be *acceptable* upstream.
At a quick glance, it looks like the wpa_supplicant one at least would
not be, because I think it'll break the build with OpenSSL <= 1.0.2.

> > We'd probably want to *stop* using /usr/include/openssl in that case;
> > the pkg-config files can set the include path, so everyone should cope
> > with that, and we don't want them accidentally picking up the *wrong*
> > header files.
> 
> I currently did not want to do that as some dependent packages might
> not use pkg-config and would have to be patched to use the different
> include directory anyway.

Some might not but most would, and all SHOULD. If we did ship parallel
-devel packages, then I really think we'd need to move them. So then we
get a nice clean failure and not a horrid mismatch of headers which
might lead to more subtle bugs.

But if we don't want to ship parallel -devel packages, that's fine.

> > But then again what happens when we end up with both versions of
> > OpenSSL loaded into a process? Even if we've converted everything in
> > Fedora and it's only third-party stuff that still uses a compat-1.0.2
> > package... if it loads other Fedora libraries which are using 1.1, we
> > end up with both. Isn't that going to end in tears? Is it even viable
> > to ship both at once? Or do we fix that with symbol versioning?
> 
> I've tested some scenarios - particularly running Apache with mod_ssl
> and libkrb5 linked to 1.0.2 and mod_auth_gssapi linked to 1.1.0 worked
> fine. So hopefully the symbol versioning works and allows this.

Great. I've seen occasional problems but I've been doing my own local
builds of random versions of OpenSSL, without the --default-symver that
our package adds.

-- 
dwmw2


smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[Tomas Mraz]

On Po, 2016-09-26 at 09:35 +0100, David Woodhouse wrote:
> On Mon, 2016-09-26 at 10:09 +0200, Tomas Mraz wrote:
> > 
> > My current plan is to not ship such engine-pkcs11 package. We
> > should
> > try to move everything to OpenSSL 1.1 and ship the 1.0.2 only as a
> > compat package for third party binaries without -devel and any
> > extra
> > bells and whistles. It would be also temporarily used in Rawhide so
> > it
> > is installable but for that I think we can live with temporarily
> > breaking PKCS#11 uri support.
> If we move everything to 1.1 and nothing that *currently* supports
> PKCS#11 ends up broken in F26 because it's left behind on 1.0.2, then
> that works.
> 
> Although building the engine alone for 1.0.2, without shipping a
> matching version of libp11 alongside it, would also be feasible.
> 
> As for shipping without -devel... do we have a flag day in rawhide
> and
> just switch, either fixing the resulting FTBFS issues afterwards, or
> having had the fixes waiting in the wings to push to all the affected
> packages?

My current plan is to just switch and rebuild fixing the FTBFS during
that. I want to persuade some of my colleagues to help me with that
(and of course community help is also welcome).

Also we will be sharing the work with other downstream distributions
here:
https://github.com/patch-exchange/openssl-1.1-transition


> I was imagining that we'd deploy the new OpenSSL 1.1 package but
> still
> allow other packages to build against 1.0.2 if they need to, at least
> for a little while — even if we plan to kill the 1.0.2 -devel package
> before we actually ship F26?
> 
> We'd probably want to *stop* using /usr/include/openssl in that case;
> the pkg-config files can set the include path, so everyone should
> cope
> with that, and we don't want them accidentally picking up the *wrong*
> header files.

I currently did not want to do that as some dependent packages might
not use pkg-config and would have to be patched to use the different
include directory anyway.

> But then again what happens when we end up with both versions of
> OpenSSL loaded into a process? Even if we've converted everything in
> Fedora and it's only third-party stuff that still uses a compat-1.0.2
> package... if it loads other Fedora libraries which are using 1.1, we
> end up with both. Isn't that going to end in tears? Is it even viable
> to ship both at once? Or do we fix that with symbol versioning?

I've tested some scenarios - particularly running Apache with mod_ssl
and libkrb5 linked to 1.0.2 and mod_auth_gssapi linked to 1.1.0 worked
fine. So hopefully the symbol versioning works and allows this.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[David Woodhouse]

On Mon, 2016-09-26 at 10:09 +0200, Tomas Mraz wrote:
> My current plan is to not ship such engine-pkcs11 package. We should
> try to move everything to OpenSSL 1.1 and ship the 1.0.2 only as a
> compat package for third party binaries without -devel and any extra
> bells and whistles. It would be also temporarily used in Rawhide so it
> is installable but for that I think we can live with temporarily
> breaking PKCS#11 uri support.

If we move everything to 1.1 and nothing that *currently* supports
PKCS#11 ends up broken in F26 because it's left behind on 1.0.2, then
that works.

Although building the engine alone for 1.0.2, without shipping a
matching version of libp11 alongside it, would also be feasible.

As for shipping without -devel... do we have a flag day in rawhide and
just switch, either fixing the resulting FTBFS issues afterwards, or
having had the fixes waiting in the wings to push to all the affected
packages?

I was imagining that we'd deploy the new OpenSSL 1.1 package but still
allow other packages to build against 1.0.2 if they need to, at least
for a little while — even if we plan to kill the 1.0.2 -devel package
before we actually ship F26?

We'd probably want to *stop* using /usr/include/openssl in that case;
the pkg-config files can set the include path, so everyone should cope
with that, and we don't want them accidentally picking up the *wrong*
header files.

But then again what happens when we end up with both versions of
OpenSSL loaded into a process? Even if we've converted everything in
Fedora and it's only third-party stuff that still uses a compat-1.0.2
package... if it loads other Fedora libraries which are using 1.1, we
end up with both. Isn't that going to end in tears? Is it even viable
to ship both at once? Or do we fix that with symbol versioning?

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[Tomas Mraz]

On So, 2016-09-24 at 00:52 +0100, David Woodhouse wrote:
> On Tue, 2016-09-20 at 11:37 +0200, Tomas Mraz wrote:
> > 
> > Well... we certainly need to port it sooner or later although I
> > understand that effort will be quite non-trivial.
> You mean port libp11? That's already working against OpenSSL 1.1,
> isn't
> it? We just need to ensure we can ship a version of libp11 — or at
> least the engine — for both OpenSSL 1.1 and OpenSSL 1.0.2, if we're
> going to ship them both in parallel.

Ah, that's a good news. I did not get to try to rebuild it against
OpenSSL1.1 yet.

My current plan is to not ship such engine-pkcs11 package. We should
try to move everything to OpenSSL 1.1 and ship the 1.0.2 only as a
compat package for third party binaries without -devel and any extra
bells and whistles. It would be also temporarily used in Rawhide so it
is installable but for that I think we can live with temporarily
breaking PKCS#11 uri support.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[David Woodhouse]

On Tue, 2016-09-20 at 11:37 +0200, Tomas Mraz wrote:
> Well... we certainly need to port it sooner or later although I
> understand that effort will be quite non-trivial.

You mean port libp11? That's already working against OpenSSL 1.1, isn't
it? We just need to ensure we can ship a version of libp11 — or at
least the engine — for both OpenSSL 1.1 and OpenSSL 1.0.2, if we're
going to ship them both in parallel.

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[Tomas Mraz]

On Pá, 2016-09-16 at 15:06 +0100, David Woodhouse wrote:
> On Fri, 2016-09-16 at 15:39 +0200, Jan Kurik wrote:
> > 
> > We will also
> > add compat openssl102 package so the applications and other
> > dependencies which are not ported yet to the new API continue to
> > work.
> What plan do you have for libp11 and engine_pkcs11?
> 
> Packaging guidelines state that packages SHOULD support PKCS#11 URIs
> if
> they support using certificates/keys via a filename.
> 
> Which is made fairly trivial by libp11 and the engine. But only if
> it's
> actually *present* for the version of OpenSSL that you're building
> against...

Well... we certainly need to port it sooner or later although I
understand that effort will be quite non-trivial.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[David Woodhouse]

On Fri, 2016-09-16 at 16:39 +0200, Nikos Mavrogiannopoulos wrote:
> On Fri, 2016-09-16 at 16:13 +0200, Dan Horák wrote:
> > 
> > On Fri, 16 Sep 2016 15:06:13 +0100
> > David Woodhouse  wrote:
> > 
> > > 
> > > 
> > > On Fri, 2016-09-16 at 15:39 +0200, Jan Kurik wrote:
> > > > 
> > > > 
> > > > We will also
> > > > add compat openssl102 package so the applications and other
> > > > dependencies which are not ported yet to the new API continue to
> > > > work.
> > > 
> > > What plan do you have for libp11 and engine_pkcs11?
> > 
> > FWIW engine_pkcs11 got retired recently IIRC, but strangely only in
> > f25
> 
> It was retired because it is now combined with libp11. The package
> engine_pkcs11 still exists.

And I thought we'd done that in F24 too. We *certainly* shipped the
newer libp11 which obsoletes it, even if we didn't manage to properly
retire the engine_pkcs11 source package :)

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[Nikos Mavrogiannopoulos]

On Fri, 2016-09-16 at 16:13 +0200, Dan Horák wrote:
> On Fri, 16 Sep 2016 15:06:13 +0100
> David Woodhouse  wrote:
> 
> > 
> > On Fri, 2016-09-16 at 15:39 +0200, Jan Kurik wrote:
> > > 
> > > We will also
> > > add compat openssl102 package so the applications and other
> > > dependencies which are not ported yet to the new API continue to
> > > work.
> > 
> > What plan do you have for libp11 and engine_pkcs11?
> 
> FWIW engine_pkcs11 got retired recently IIRC, but strangely only in
> f25

It was retired because it is now combined with libp11. The package
engine_pkcs11 still exists.

regards,
Nikos
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[Dan Horák]

On Fri, 16 Sep 2016 15:06:13 +0100
David Woodhouse  wrote:

> On Fri, 2016-09-16 at 15:39 +0200, Jan Kurik wrote:
> > We will also
> > add compat openssl102 package so the applications and other
> > dependencies which are not ported yet to the new API continue to
> > work.
> 
> What plan do you have for libp11 and engine_pkcs11?

FWIW engine_pkcs11 got retired recently IIRC, but strangely only in f25


Dan
 
> Packaging guidelines state that packages SHOULD support PKCS#11 URIs
> if they support using certificates/keys via a filename.
> 
> Which is made fairly trivial by libp11 and the engine. But only if
> it's actually *present* for the version of OpenSSL that you're
> building against...
> 
> -- 
> dwmw2
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[David Woodhouse]

On Fri, 2016-09-16 at 15:39 +0200, Jan Kurik wrote:
> We will also
> add compat openssl102 package so the applications and other
> dependencies which are not ported yet to the new API continue to work.

What plan do you have for libp11 and engine_pkcs11?

Packaging guidelines state that packages SHOULD support PKCS#11 URIs if
they support using certificates/keys via a filename.

Which is made fairly trivial by libp11 and the engine. But only if it's
actually *present* for the version of OpenSSL that you're building
against...

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F26 System Wide Change: OpenSSL 1.1.0

[Jan Kurik]

= Proposed System Wide Change: OpenSSL 1.1.0 =
https://fedoraproject.org/wiki/Changes/OpenSSL110


Change owner(s):
* Tomas Mraz 

Rebase of OpenSSL package to 1.1.0 version

== Detailed Description ==
Update the OpenSSL library to the 1.1.0 branch in Fedora to bring
multiple big improvements, new cryptographic algorithms, and new API
that allows for keeping ABI stability in future upgrades. We will also
add compat openssl102 package so the applications and other
dependencies which are not ported yet to the new API continue to work.


== Scope ==
* Proposal owners:
Prepare and test rebased openssl package. Prepare and test compat
openssl102 package. Help with patching and rebuilding dependent
packages.

* Other developers:
Patch and rebuild your package if it uses OpenSSL library (proposal
owner will help).

* Release engineering:
N/A unless we decide that separate branch is needed. Mass rebuild will
not help as the packages have to be patched for the API changes.

* List of deliverables:
N/A

* Policies and guidelines:
N/A

* Trademark approval:
N/A
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org