Re: compat-openssl11 vs openssl1.1

[Tomas Mraz]

On Tue, 2020-09-15 at 19:33 +0200, Miro Hrončok wrote:
> On 15. 09. 20 19:26, Tomas Mraz wrote:
> > What is more important? Consistency between those two compat
> > packages
> > or strictly following the naming rules for the new package?
> 
> Why not both? I.e. renaming compat-openssl10 to openssl1.0 while
> packaging 
> openssl1.1?
> 
> Note that I've always considered the compat-openssl10 name quite
> confusing, so I 
> would prefer the new one to be openssl1.1 (even if you don't rnemae
> the old one).

I do not think it is worth it to rename the old one and I am not even
maintainer of it in Fedora anymore. It should be dropped ASAP as it is
release without upstream support.

So OK, I'll use openssl1.1 for the new one.
-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

compat-openssl11 vs openssl1.1

[Tomas Mraz]

Hi Fedora developers,

we need to introduce temporarily a compat package for OpenSSL as it is
going to be rebased to the 3.0 version in Rawhide once the 3.0 release
is stable.

The 3.0 version should not break API from the 1.1.1, it just breaks the
ABI, so rebuilds should be quite easy. Of course there might be minor
breakage and adjustments needed especially for the language bindings.
But anyway to help with the transition there should temporarily be a
compat package with the openssl-1.1.1.

I've submitted a new compat-openssl11 package for review but it was
pointed out to me that according to the new format of the naming for
compat packages it should be named openssl1.1. However there already is
a compat-openssl10 package.

What is more important? Consistency between those two compat packages
or strictly following the naming rules for the new package?

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Tomas Mraz]

On Wed, 2020-04-15 at 10:02 -0500, Michael Catanzaro wrote:
> On Wed, Apr 15, 2020 at 1:38 pm, Florian Weimer  
> wrote:
> > Not sure if that's compatible with the new split DNS model because 
> > VPN1
> > could simply start pushing longer names in the scope of VPN2, thus
> > hijacking internal traffic there (and this sort of hijacking is 
> > exactly
> > what a DNS sinkhole against typosquatting would need).
> 
> You deserve bonus points for thinking like an attacker and exploring 
> the security model, but let's assume the configured VPNs are
> trusted. 
> Otherwise the user is screwed no matter what. ;)

Trusted for what? I would expect corporate VPNs doing such tricks to
monitor the user's internet traffic. Which does not mean the user is
fully screwed with such VPN if he for example uses hardcoded
configuration of a caching nameserver.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: OpenSSL 3.0

[Tomas Mraz]

On Wed, 2020-04-08 at 10:38 +0200, Miro Hrončok wrote:
> On 07. 04. 20 23:31, Ben Cotton wrote:
> > * Proposal owners: Provide a compat-openssl11 package, identify
> > dependent packages, provide the rebased openssl package, work with
> > dependent package owners on rebuilds.
> 
> Thanks for doing this.
> 
> Will compat-openssl11-devel be provided? For how long you intent to
> support it?

I originally thought that we might be able to do without the -devel
subpackage as there are the usual problems with it - such as it being
conflicting with the primary openssl-devel package and also potential
for unstability in applications that have loaded both old and new
OpenSSL into a single process.

> E.g. I don't see Python 2 ever supporting openssl 3, that's why I'm
> asking.

The question is what does this really mean - in theory at least the API
should be fully backwards compatible so what builds against openssl
1.1.1 should build against openssl 3. Of course testcases that expect
bug-for-bug compatibility might not work as expected.

But yeah I am not against providing compat-openssl11-devel for a few
releases at least. And I can orphan the package later if someone else
wants to maintain it further then.

> (Replied this sooner, but accidentally to devel-announce.)
> 
> -- 
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Heads up: OpenSSL-1.1.1e coming to Rawhide

[Tomas Mraz]

On Thu, 2020-03-26 at 17:11 +0100, Miro Hrončok wrote:
> On 26. 03. 20 17:07, Tomas Mraz wrote:
> > On Wed, 2020-03-25 at 09:34 +0100, Miro Hrončok wrote:
> > > On 24. 03. 20 13:22, Tomas Mraz wrote:
> > > > Most probably we will revert this
> > > > change in upstream 1.1.1 branch and I will update the rawhide
> > > > build
> > > > with the revert patch as well.
> > > 
> > > Can this please happen rather sooner than later?
> > 
> > I've built openssl-1.1.1e-2.fc33 with the EOF handling change
> > reverted
> > today.
> > 
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=1482948
> 
> Thanks a lot.
> 
> > > The list of (likely) affected packages is growing:
> > > 
> > > https://koschei.fedoraproject.org/affected-by/openssl-libs?epoch1=1=1.1.1d=7.fc33=1=1.1.1e=1.fc33=f33
> > > 
> > > It shows that this does not only break Python's own test suite,
> > > but
> > > various
> > > Python packages are failing as well (incl. python-pip).
> > > 
> > > This blocks the testing rebuilds with Python 3.9.0a5 (reporting
> > > way
> > > too many
> > > unrelated FTBFSes).
> > 
> > Unless OpenSSL upstream decides otherwise we will however have this
> > issue later in Fedora 33 development when the rebase to 3.0
> > happens. Of
> > course the rebase to 3.0 will be disruptive in more ways and so it
> > should be done in a side-tag first.
> 
> Do you have at least a rough estimate for when should we expect this?
> 
> E.g. is it going to be after mid-May or before?

I have to say that the schedule of the OpenSSL 3.0 release is a little
bit conflicting with the F33 schedule. However I should be able to have
a rebase to a beta version of OpenSSL 3.0 prepared at the end of June.

Of course depending on the problems with the dependent package rebuilds
in the side-tag we will see if the 3.0 would be viable for the Fedora
33 at all.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Heads up: OpenSSL-1.1.1e coming to Rawhide

[Tomas Mraz]

On Wed, 2020-03-25 at 09:34 +0100, Miro Hrončok wrote:
> On 24. 03. 20 13:22, Tomas Mraz wrote:
> > Most probably we will revert this
> > change in upstream 1.1.1 branch and I will update the rawhide build
> > with the revert patch as well.
> 
> Can this please happen rather sooner than later?

I've built openssl-1.1.1e-2.fc33 with the EOF handling change reverted
today.

https://koji.fedoraproject.org/koji/buildinfo?buildID=1482948

> The list of (likely) affected packages is growing:
> 
> https://koschei.fedoraproject.org/affected-by/openssl-libs?epoch1=1=1.1.1d=7.fc33=1=1.1.1e=1.fc33=f33
> 
> It shows that this does not only break Python's own test suite, but
> various 
> Python packages are failing as well (incl. python-pip).
> 
> This blocks the testing rebuilds with Python 3.9.0a5 (reporting way
> too many 
> unrelated FTBFSes).

Unless OpenSSL upstream decides otherwise we will however have this
issue later in Fedora 33 development when the rebase to 3.0 happens. Of
course the rebase to 3.0 will be disruptive in more ways and so it
should be done in a side-tag first.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Heads up: OpenSSL-1.1.1e coming to Rawhide

[Tomas Mraz]

On Tue, 2020-03-24 at 09:52 -0400, Charalampos Stratakis wrote:
> 
> - Original Message -
> > From: "Tomas Mraz" 
> > To: "Miro Hrončok" , "Development discussions
> > related to Fedora" 
> > Cc: "python-maint" 
> > Sent: Tuesday, March 24, 2020 1:22:37 PM
> > Subject: Re: Heads up: OpenSSL-1.1.1e coming to Rawhide
> > 
> > On Sun, 2020-03-22 at 17:29 +0100, Miro Hrončok wrote:
> > > On 19. 03. 20 17:31, Tomas Mraz wrote:
> > > > The new openssl-1.1.1e is coming to Rawhide.
> > > > 
> > > > It reports premature EOF/improper shutdown on TLS connections
> > > > more
> > > > properly. However this might make some dependencies broken in
> > > > build
> > > > tests (such as Ruby).
> > > > 
> > > > As I would like to eventually update the openssl also on stable
> > > > branches because it brings many bugfixes please consider
> > > > bringing
> > > > eventual fixes/workarounds in depending packages also there.
> > > 
> > > Packages failing to build:
> > > 
> > > https://koschei.fedoraproject.org/affected-by/openssl?epoch1=1=1.1.1d=7.fc33=1=1.1.1e=1.fc33=f33
> > > 
> > > https://koschei.fedoraproject.org/affected-by/openssl-devel?epoch1=1=1.1.1d=7.fc33=1=1.1.1e=1.fc33=f33
> > > 
> > > That includes Python interpreters.
> > > 
> > > We have Python tests defined in the CI:
> > > 
> > > https://src.fedoraproject.org/rpms/openssl/blob/master/f/tests/tests_python.yml
> > > 
> > > Why have this upgrade never been tested that way?
> > 
> > I knew there will be actual problems so that is the reason why I
> > sent
> > the heads up. Next time I'll make sure the CI is run as well, not
> > sure
> > if it would make any difference in this case apart from maybe I
> > would
> > open bugs right away?
> 
> With the PR workflow on pagure, the CI would be run and we can check
> out the issues that might appear on the python side at least, as we
> have added the relevant python tests in the openssl pagure repo. So
> indeed it would help a lot.
> 
> > > Please do not push this to older releases until we fix this.
> > 
> > I will not push it to older releases. Most probably we will revert
> > this
> > change in upstream 1.1.1 branch and I will update the rawhide build
> > with the revert patch as well. Anyway this change is going to stay
> > in
> > the master branch of OpenSSL (for 3.0.0) so it is a good idea to be
> > able to handle it in the dependencies anyway.
> > 
> 
> That would be great actually, thanks for considering it. Pushing this
> change for the 3.0.0 version of OpenSSL should provide us with enough
> time to iron out everything.
> 
> On a side note, is there some upstream CI of OpenSSL where we could
> maybe test its integration with Python, or other projects? From the
> python upstream CI side, where we use the buildbot software, we
> noticed that when the fedora servers running the builds got the
> openssl package updated, the tests started failing. Maybe something
> similar could be implemented for OpenSSL, depending of course if the
> infrastructure is in place.

There is already pyca-cryptography build and testsuite run in the
external tests. Perhaps some more python related stuff could be added
although I am not sure the way it is currently integrated would allow
much bigger testsuites being run.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Heads up: OpenSSL-1.1.1e coming to Rawhide

[Tomas Mraz]

On Sun, 2020-03-22 at 17:29 +0100, Miro Hrončok wrote:
> On 19. 03. 20 17:31, Tomas Mraz wrote:
> > The new openssl-1.1.1e is coming to Rawhide.
> > 
> > It reports premature EOF/improper shutdown on TLS connections more
> > properly. However this might make some dependencies broken in build
> > tests (such as Ruby).
> > 
> > As I would like to eventually update the openssl also on stable
> > branches because it brings many bugfixes please consider bringing
> > eventual fixes/workarounds in depending packages also there.
> 
> Packages failing to build:
> 
> https://koschei.fedoraproject.org/affected-by/openssl?epoch1=1=1.1.1d=7.fc33=1=1.1.1e=1.fc33=f33
> 
> https://koschei.fedoraproject.org/affected-by/openssl-devel?epoch1=1=1.1.1d=7.fc33=1=1.1.1e=1.fc33=f33
> 
> That includes Python interpreters.
> 
> We have Python tests defined in the CI:
> 
> https://src.fedoraproject.org/rpms/openssl/blob/master/f/tests/tests_python.yml
> 
> Why have this upgrade never been tested that way?

I knew there will be actual problems so that is the reason why I sent
the heads up. Next time I'll make sure the CI is run as well, not sure
if it would make any difference in this case apart from maybe I would
open bugs right away?

> Please do not push this to older releases until we fix this.

I will not push it to older releases. Most probably we will revert this
change in upstream 1.1.1 branch and I will update the rawhide build
with the revert patch as well. Anyway this change is going to stay in
the master branch of OpenSSL (for 3.0.0) so it is a good idea to be
able to handle it in the dependencies anyway.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Heads up: OpenSSL-1.1.1e coming to Rawhide

[Tomas Mraz]

The new openssl-1.1.1e is coming to Rawhide.

It reports premature EOF/improper shutdown on TLS connections more
properly. However this might make some dependencies broken in build
tests (such as Ruby).

As I would like to eventually update the openssl also on stable
branches because it brings many bugfixes please consider bringing
eventual fixes/workarounds in depending packages also there.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Python 2 exodus is happening now

[Tomas Mraz]

On Fri, 2019-11-15 at 02:02 +0100, Miro Hrončok wrote:
> system-config-rootpassword

Fixed to use python3 in system-config-rootpassword-1.99.6-21.fc32,
please do not retire.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

compat-openssl10 is now orphaned

[Tomas Mraz]

This is just an announcement that the compat-openssl10 package is now
orphaned.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 Self-Contained Change proposal: Limit Scriptlet Usage of core packages

[Tomas Mraz]

On Thu, 2019-07-04 at 09:03 -0700, Adam Williamson wrote:
> On Thu, 2019-07-04 at 11:38 +0200, Tomas Mraz wrote:
> > OK, let's talk about concrete package: crypto-policies needs to run
> > update-crypto-policies --no-check >/dev/null
> > 
> > It currently does it in %post.
> > 
> > It could do it in %posttrans - that would be one option.
> 
> Presumably only if no other package being installed needed correct
> crypto policies for its scriptlets?

Well, there would be _some_ configuration present from the crypto-
policy package install at least. And on updates there will be the
previous version. So this would be needed only in case the policy was
for some reason broken in the previous version and we are doing an
update and want to fix the breakage for the other packages scriptlets.

I think this is a fairly obscure scenario that we can ignore unless
there is any other non-obscure way how to avoid it.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 Self-Contained Change proposal: Limit Scriptlet Usage of core packages

[Tomas Mraz]

On Mon, 2019-07-01 at 17:18 -0400, James Antill wrote:
> On Mon, 2019-07-01 at 17:03 -0400, Robbie Harwood wrote:
> > Ben Cotton  writes:
> > 
> > > == Detailed Description ==
> > > 
> > > Currently we know how to make an installable OS with packages
> > > that
> > > doesn't require the use of scriptlets, indeed rpm-ostree and
> > > others
> > > have already done this on a significantly bigger scale. So we
> > > plan
> > > to
> > > remove direct scriptlets from most (if not all) of the packages
> > > in
> > > the
> > > main fedora container image for Fedora 31. This means all four
> > > of:
> > > %pre/%post/%preun/%postun. After this change it'd be good to have
> > > some
> > > kind of temporary exception to be granted before those packages
> > > could
> > > add a scriptlet back (post F31 work).
> > 
> > Do I understand correctly that triggers aren't affected here?
> 
>  Yes.
> 
> > > Almost all of the hard work is already done, as rpm can react to
> > > files
> > > being dropped in specified places with known actions (Eg. In this
> > > way
> > > systemd components can create users or files). There are a few
> > > minor
> > > changes needed to packages to move from the old way of doing
> > > things
> > > (Eg. calling adduser) to doing the new thing. Note that while a
> > > program will still be run at installation time, those programs
> > > will
> > > be
> > > few and easily audited (as against the 666 slightly different
> > > ways
> > > of
> > > adding a user we currently have).
> > 
> > Is there a document describing common things that are done with
> > scriptlets and the "proper", non-scriptlet way to do them?  (If
> > not,
> > could one be made?)
> 
>  I don't believe there is a single document atm. ... I could look at
> putting one somewhere, although it's a bit like lumping random things
> together because we happen to be doing them at the same time.

OK, let's talk about concrete package: crypto-policies needs to run
update-crypto-policies --no-check >/dev/null

It currently does it in %post.

It could do it in %posttrans - that would be one option. What are the
other options?

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

[Tomas Mraz]

On Tue, 2019-06-25 at 07:16 -0400, Nico Kadel-Garcia wrote:
> On Wed, Jun 19, 2019 at 9:31 AM Panu Matilainen 
> wrote:
> > On 6/19/19 1:51 PM, Aleš Matěj wrote:
> > > > At this point, the drpm library is the only blocker for zstd
> > > > payloads,
> > > > since createrepo_c needs to be able to handle zstd drpms.
> > > 
> > > I looked into the drpm library and I should be able to add the
> > > zstd support
> > > (and make sure it works with createrepo_c)
> > > 
> > > Working on it now.
> > 
> > FWIW, as drpm links to librpm anyway, it should be possible for
> > drpm to
> > just use the file API from rpm to gain support for everything that
> > rpm
> > does instead of duplicating the effort for all the compression
> > types.
> > 
> > If there's something broken or missing that prevents this from
> > working,
> > we could always address that...
> > 
> > - Panu -
> 
> This whole zstd replacement seems like a hazardous idea, because of
> backporting SRPMs to older operating systems for EPEL compilation.
> It's possible, but awkward, to chew through the git repos to deduce
> whch git branch was used and reference that, rather than directly
> extract from the SRPM. It would mean that unless this compression is
> only applied to limited uses such as drpm, then older OS releases
> would not be able to read the modern SRPM by default. Backwards
> compatibility is not why people write new software, but broad
> accessibility of the source code seems a vital feature to preserve
> for
> what should be rock stable build environments downstream.
> 
> I, for one, have done considerable backporting of Fedora SRPMs of
> python modules to RHEL and CentOS environments. I'd hate to add
> another step to extract them on RHEL or CentOS or to build from them
> in "mock". I'd also hate for "rpm2cpio" to break: I hope adding zstd
> compatibility to the older versions of that tool, as well, is not
> difficult.

This is change is strictly only about binary rpm payload compression
method change not at all about SRPMs.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F31 Self-Contained Change proposal: Custom Crypto Policies

[Tomas Mraz]

On Wed, 2019-06-19 at 12:38 +0200, Vít Ondruch wrote:
> Dne 18. 06. 19 v 21:50 Ben Cotton napsal(a):
> > == How To Test ==
> > 
> > This will be tested as part of the upstream crypto-policies
> > testsuite.
> 
> I think this section should describe, how I, as a Fedora user, am
> supposed to test this. E.g.
> 
> 1) Get this test package
> 
> 2) Modify this file
> 
> 3) Run this command
> 
> 4) And as a result, you can now verify by this command that this new
> crypto-policy is applied.

As this is self-contained change I am not sure this is necessary.
However I might provide test instructions or rather some kind of how-to 
as part of the crypto-policies documentation.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F31 Self-Contained Change proposal: Custom Crypto Policies

[Tomas Mraz]

On Wed, 2019-06-19 at 12:49 +0200, Vít Ondruch wrote:
> Dne 19. 06. 19 v 12:00 Tomas Mraz napsal(a):
> > On Wed, 2019-06-19 at 10:19 +0200, Vít Ondruch wrote:
> > > Dne 18. 06. 19 v 21:50 Ben Cotton napsal(a):
> > > > https://fedoraproject.org/wiki/Changes/CustomCryptoPolicies
> > > > 
> > > > == Summary ==
> > > > This new feature of crypto-policies allows system
> > > > administrators
> > > > and
> > > > third party providers to modify and adjust the existing system-
> > > > wide
> > > > crypto policies to enable or disable algorithms and protocols.
> > > > 
> > > > == Owner ==
> > > > * Name: [[User:Tmraz | Tomáš Mráz]]
> > > > * Email: tm...@redhat.com
> > > > 
> > > > == Detailed Description ==
> > > > 
> > > > The crypto-policies package will be enhanced to allow system
> > > > administrators to modify the existing system-wide crypto policy
> > > > levels
> > > > by removing or adding enabled algorithms and protocols. For
> > > > example
> > > > it
> > > > will be possible to easily modify the existing DEFAULT
> > > I just wonder what is the strategy here? Does it means that the
> > > "DEFAULT" definition will be store permanently somewhere in /usr/
> > > and
> > > I'll be able to copy the DEFAULT into /etc and modify it
> > > according to
> > > my
> > > needs?
> > > 
> > > I am just asking, because AFAIK, currently the crypto policies
> > > configuration is stored just in /etc and modifying the "DEFAULT"
> > > profile
> > > would make the updates problematic, requiring someone to file
> > > with
> > > .rpmnew files etc. That would be unfortunate.
> > The configuration files will be created by a simple python
> > application
> > (which the update-crypto-policies will transform into). You will
> > specify just the modifications that should be done to the base
> > policy.
> > 
> > Please see 
> > https://gitlab.com/redhat-crypto/fedora-crypto-policies/tree/custom-policies
> >  
> > to get the idea.
> > 
> > We might continue shipping the "unmodified" configurations in
> > /usr/share but I do not see much benefit in that except for being
> > able
> > for the sysadmin to look at how the unmodified individual
> > configurations look like without applying the policy to the system.
> > 
> 
> Looking at "unmodified" configuration is great benefit on itself.

Unmodified from what? What I meant above were the unmodified pristine
DEFAULT, LEGACY, FUTURE or FIPS configurations, not something like 
library default configuration without crypto policies.

> Being able to `rm -rf /etc/cryptopolicies` (or whatever is the right
> folder) to restore the original configuration would be even better.
> But
> maybe the "update-crypto-policies" creates configuration files for
> several cryptolibraries, so this might not be possible without
> modification of those libraries, dunno.

But no such thing was ever possible since crypto policies were
introduced and there is currently no plan to do that.

This is certainly out of scope for the Custom Crypto Policies change.

I am also not sure what do you mean exactly by "original configuration"
- do you mean the configuration if there was no crypto-policies on the
system? Then that would require more configuration handling changes on
the individual crypto backend libraries/applications.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F31 Self-Contained Change proposal: Custom Crypto Policies

[Tomas Mraz]

On Wed, 2019-06-19 at 10:19 +0200, Vít Ondruch wrote:
> Dne 18. 06. 19 v 21:50 Ben Cotton napsal(a):
> > https://fedoraproject.org/wiki/Changes/CustomCryptoPolicies
> > 
> > == Summary ==
> > This new feature of crypto-policies allows system administrators
> > and
> > third party providers to modify and adjust the existing system-wide
> > crypto policies to enable or disable algorithms and protocols.
> > 
> > == Owner ==
> > * Name: [[User:Tmraz | Tomáš Mráz]]
> > * Email: tm...@redhat.com
> > 
> > == Detailed Description ==
> > 
> > The crypto-policies package will be enhanced to allow system
> > administrators to modify the existing system-wide crypto policy
> > levels
> > by removing or adding enabled algorithms and protocols. For example
> > it
> > will be possible to easily modify the existing DEFAULT
> 
> I just wonder what is the strategy here? Does it means that the
> "DEFAULT" definition will be store permanently somewhere in /usr/ and
> I'll be able to copy the DEFAULT into /etc and modify it according to
> my
> needs?
> 
> I am just asking, because AFAIK, currently the crypto policies
> configuration is stored just in /etc and modifying the "DEFAULT"
> profile
> would make the updates problematic, requiring someone to file with
> .rpmnew files etc. That would be unfortunate.

The configuration files will be created by a simple python application
(which the update-crypto-policies will transform into). You will
specify just the modifications that should be done to the base policy.

Please see 
https://gitlab.com/redhat-crypto/fedora-crypto-policies/tree/custom-policies 
to get the idea.

We might continue shipping the "unmodified" configurations in
/usr/share but I do not see much benefit in that except for being able
for the sysadmin to look at how the unmodified individual
configurations look like without applying the policy to the system.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: wpa supplicant using /dev/random

[Tomas Mraz]

On Wed, 2019-06-05 at 16:38 -0600, Chris Murphy wrote:
> Jun 05 15:53:25 fmac.local kernel: random: crng init done
> Jun 05 15:53:25 fmac.local kernel: random: 7 urandom warning(s)
> missed
> due to ratelimiting
> Jun 05 15:53:25 fmac.local wpa_supplicant[1000]: random: Cannot read
> from /dev/random: Resource temporarily unavailable
> Jun 05 15:53:25 fmac.local wpa_supplicant[1000]: random: Got 20/20
> bytes from /dev/random
> 
> 
> Is this a bug? Should it be using /dev/urandom instead?

That's clearly a bug. It should just use OpenSSL which it links to
anyway to get random numbers. OpenSSL uses getrandom() to get entropy
from the kernel to seed its RNG.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

[Tomas Mraz]

On Thu, 2019-05-30 at 16:18 -0400, Neal Gompa wrote:
> 
> That said, I'm less happy about the thought that inspecting Fedora
> RPMs on RHEL 8 or openSUSE is going to be a royal pain.
> Ecosystem-wise, no one really prepared for a distribution to switch
> to
> zstd so quickly. Thankfully, it's easier to support than things like
> modularity, which break the entire way people do things. If we decide
> to do this, at least I'll try to see to get things fixed on the SUSE
> side. Maybe someone can push for this to be fixed on the RHEL side as
> well?

I created this BZ:

https://bugzilla.redhat.com/show_bug.cgi?id=1715799

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: rpmlint warning: crypto-policy-non-compliance-gnutls-1

[Tomas Mraz]

Anderson, FYI. Could you please answer the question below?

On Fri, 2019-05-24 at 17:58 +0100, Richard W.M. Jones wrote:
> > libnbd.x86_64: W: crypto-policy-non-compliance-gnutls-1
> > /usr/lib64/libnbd.so.0.0.0 gnutls_priority_set_direct
> > This application package calls a function to explicitly set crypto
> > ciphers for
> > SSL/TLS. That may cause the application not to use the system-wide
> > set
> > cryptographic policy and should be modified in accordance to:
> > https://fedoraproject.org/wiki/Packaging:CryptoPolicies
> 
> The library does call gnutls_priority_set_direct, but in a way which
> I
> believe still uses the system policies:
> 
>   %prep
>   ./configure --with-tls-priority=@LIBNBD,SYSTEM
> 
> sets ...
> 
>   #define TLS_PRIORITY "@LIBNBD,SYSTEM"
> 
> which calls ...
> 
>   err = gnutls_priority_set_direct (session, TLS_PRIORITY, NULL);
> 
> So we're good and we can ignore this warning, right?
> 
> I should note that I copied this coding pattern from libvirt.
> 
> Rich.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Removal of krb5-devel from "stable" F29 buidroot broke my package

[Tomas Mraz]

On Thu, 2019-05-16 at 07:50 +0200, Vít Ondruch wrote:
> Dne 15. 05. 19 v 17:29 Dominique Martinet napsal(a):
> > Michal Schorm wrote on Wed, May 15, 2019 at 05:14:23PM +0200:
> > > Another possible cause came up my mind.
> > > 
> > > Another package in the buildroot could have brought it as a
> > > dependency, but does not bring it anymore ?
> > Yeah, it used to come with openssl-devel, but got removed very
> > recently:
> > https://src.fedoraproject.org/rpms/openssl/c/7a654fc69c499b54f38543ca40f765fbaf9bdf84
> > 
> 
> This was removed on my request, triggered by this PR [1].
> Nevertheless I
> concur that this should happen just in Rawhide and never be
> backported
> into stable releases.

Well... that's debatable. There is no promise that the stable releases
won't break broken packages working only accidentaly. The fix is simple
add the proper build dependency if you need it and do not depend on it
being pulled in by something else.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Can we maybe reduce the set of packages we install by default a bit?

[Tomas Mraz]

On Wed, 2019-04-24 at 14:16 +0200, Lennart Poettering wrote:
> On Mi, 24.04.19 12:37, Nikos Mavrogiannopoulos (n...@redhat.com)
> wrote:
> 
> > > As mentioned before: systemd itself already needs entropy itself
> > > (it
> > > assigns a random 128bit id to each service invocation, dubbed the
> > > "invocation ID" of it, and it generates the machine ID and seeds
> > > its
> > > hash table hash functions), hence rngd doesn't cut it anyway,
> > > since it
> > > starts after systemd, being a service managed by systemd. If rngd
> > > was
> > > supposed to fill up the entropy pool at boot, it would have to
> > > run as
> > > initial PID 1 in the initrd, before systemd, and then hand over
> > > to
> > > systemd only after the pool is full. But it doesn't, hence rngd
> > > is
> > > pointless: it runs too late to be useful.
> > 
> > The goal of running rngd early was to have the system boot, not
> > necessarily to address systemd's need for random numbers. In that
> > it
> > is successful. I do not disagree that it is not a clean solution.
> 
> But how can it be successful? If systemd already needs to wait until
> the pool is full to get the randomness it needs (and thus blocks
> system boot-up as a whole) then what's the point in running rngd
> afterwards? To reach the point where rngd can be run we already need
> the pool to be full, and hence rngd can't do any good at all anymore,
> whatsoever.

What does systemd use to generate these random numbers? Does it
directly call getrandom() or does something else?

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How to submit Root CA to ship with Fedora

[Tomas Mraz]

On Wed, 2019-04-24 at 09:15 +0200, Dominik 'Rathann' Mierzejewski
wrote:
> Hi,
> 
> On Wednesday, 24 April 2019 at 08:05, Danishka Navin wrote:
> > Sri Lanka Cert is gonna implement local Root CA.
> > How we can submit this Root CA with Fedora?
> > 
> > I could not find enough information on this.
> 
> The best path would be to get it included in Mozilla's root CA trust
> store, which Fedora consumes.

It is not just the best path but basically it is the only path. Fedora
does not maintain its own list of trusted root CA but it directly
consumes the Mozilla's list.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 30 System-Wide Change Proposal: GnuPG2 as default GPG implementation

[Tomas Mraz]

On Mon, 2018-11-26 at 09:59 -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/GnuPG2_as_default_GPG_implemen
> tation
> 
> == Summary ==
> The /usr/bin/gpg path representing the main GPG implementation will
> now use GnuPG 2 instead of GnuPG 1.

I, as the primary maintainer of the gnupg2 package, welcome this change
and I will cooperate on its implementation if it is acked by FESCo.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Koji: builds fails with "error retrieving sources"

[Tomas Mraz]

On Fri, 2018-09-21 at 10:33 -0400, Scott Talbert wrote:
> On Fri, 21 Sep 2018, Scott Talbert wrote:
> 
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=29796611
> > > 
> > > It's not very clear what the actual error is, but I am fairly
> > > sure
> > > that I have uploaded the correct sources for this:
> > > 
> > > $ fedpkg new-sources libguestfs-1.39.10.tar.gz
> > > /usr/lib/python2.7/site-packages/fedora/client/bodhi.py:48: 
> > > DeprecationWarning: fedora.client.bodhi has been deprecated.
> > > Please use 
> > > bodhi.client.bindings instead.
> > >  DeprecationWarning)
> > > File already uploaded: libguestfs-1.39.10.tar.gz
> > > Source upload succeeded. Don't forget to commit the sources file
> > 
> > It looks like there is some problem keeping 'fedpkg' from being
> > installed:
> > DEBUG util.py:439: 
> > ===
> > =
> > DEBUG util.py:439:   Group   Packages
> > DEBUG util.py:439: 
> > ===
> > =
> > DEBUG util.py:439:  Marking packages as installed by the group:
> > DEBUG util.py:439:   @srpm-build shadow-utils fedora-
> > release 
> > bash
> > DEBUG util.py:439:   Problem 1: package gnupg2-2.2.9-1.fc29.armv7hl 
> > requires 
> > libgnutls.so.30, but none of the providers can be installed
> > DEBUG util.py:439:- package gnutls-3.6.3-4.fc30.armv7hl
> > requires 
> > crypto-policies, but none of the providers can be installed
> > DEBUG util.py:439:- conflicting requests
> > DEBUG util.py:439:- nothing provides /usr/bin/grubby needed by 
> > crypto-policies-20180921-1.git391ed9f.fc30.noarch
> > DEBUG util.py:439:   Problem 2: package rpm-libs-4.14.2-
> > 1.fc30.armv7hl 
> > requires libcrypto.so.1.1, but none of the providers can be
> > installed
> > DEBUG util.py:439:- package rpm-build-4.14.2-1.fc30.armv7hl
> > requires 
> > librpm.so.8, but none of the providers can be installed
> > DEBUG util.py:439:- package openssl-libs-1:1.1.1-3.fc30.armv7hl 
> > requires 
> > crypto-policies >= 20180730, but none of the providers can be
> > installed
> > DEBUG util.py:439:- conflicting requests
> > DEBUG util.py:439:- nothing provides /usr/bin/grubby needed by 
> > crypto-policies-20180921-1.git391ed9f.fc30.noarch
> > DEBUG util.py:439:   Problem 3: package rpm-4.14.2-1.fc30.armv7hl
> > requires 
> > libarchive.so.13, but none of the providers can be installed
> > DEBUG util.py:439:- package libarchive-3.3.2-2.fc29.armv7hl
> > requires 
> > libcrypto.so.1.1, but none of the providers can be installed
> > DEBUG util.py:439:- package redhat-rpm-config-120-1.fc30.noarch 
> > requires 
> > rpm >= 4.11.0, but none of the providers can be installed
> > DEBUG util.py:439:- package openssl-libs-1:1.1.1-3.fc30.armv7hl 
> > requires 
> > crypto-policies >= 20180730, but none of the providers can be
> > installed
> > DEBUG util.py:439:- conflicting requests
> > DEBUG util.py:439:- nothing provides /usr/bin/grubby needed by 
> > crypto-policies-20180921-1.git391ed9f.fc30.noarch
> > DEBUG util.py:439:   Problem 4: package fedpkg-minimal-1.1.0-
> > 11.fc29.noarch 
> > requires curl, but none of the providers can be installed
> > DEBUG util.py:439:- package curl-minimal-7.61.1-1.fc30.armv7hl
> > requires 
> > libcurl.so.4, but none of the providers can be installed
> > DEBUG util.py:439:- package curl-7.61.1-1.fc30.armv7hl
> > requires 
> > libcrypto.so.1.1, but none of the providers can be installed
> > DEBUG util.py:439:- package libcurl-7.61.1-1.fc30.armv7hl
> > requires 
> > libcrypto.so.1.1, but none of the providers can be installed
> > DEBUG util.py:439:- package libcurl-minimal-7.61.1-
> > 1.fc30.armv7hl 
> > requires libcrypto.so.1.1, but none of the providers can be
> > installed
> > DEBUG util.py:439:- package openssl-libs-1:1.1.1-3.fc30.armv7hl 
> > requires 
> > crypto-policies >= 20180730, but none of the providers can be
> > installed
> > DEBUG util.py:439:- conflicting requests
> > DEBUG util.py:439:- nothing provides /usr/bin/grubby needed by 
> > crypto-policies-20180921-1.git391ed9f.fc30.noarch
> 
> It looks like the problem is in crypto-policies and has been fixed
> in 
> crypto-policies-20180921-2, but needs to be built in rawhide.  Can
> someone 
> do that?

I've asked for untagging the bad build however it took a little while
before the buildroot was regenerated. Now it should work fine.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List 

You can now test/use the crypto policy of future Fedora releases

[Tomas Mraz]

The current [0] crypto-policies in Rawhide contain additional policy
named as NEXT. You can switch the system to it as root via command:

update-crypto-policies --set NEXT

The difference to the current DEFAULT policy is that TLS versions 1.0
and 1.1 are disabled and the minimum key length of RSA keys and minimum
length of DH parameters are 2048 bits.

There is also a FUTURE policy which in addition to this limits also the
symmetric crypto key length to minimum of 256 bits. However as this
policy is not really useful as it does not provide post-quantum safety
for asymmetric algorithms it might be eventually dropped (aliased to
the NEXT policy).

[0] crypto-policies-20180802-1.git1626592.fc29

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HCTK64OKDIOFCO542XPE45GREH22IGML/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Tomas Mraz]

On Wed, 2018-06-13 at 00:45 -0400, Paul Wouters wrote:
> On Wed, 6 Jun 2018, Nikos Mavrogiannopoulos wrote:
> 
> > I think the debate here is whether fedora (and in general operating
> > systems) can afford to be stricter than the browsers. As an OS our
> > attack surface is much larger than the browser setup, and thus it
> > makes
> > sense (to me), to be more careful.
> 
> Your legacy interaction will also be much larger. Like connecting to
> your home wifi router's webgui.
> 
> > Can we afford to break a significant part of our users? Of course
> > not,
> > but I think that this change is eventually happening, especially
> > with
> > TLS1.3 expected to be deployed widely, and it seems to me that we
> > only
> > wait to see who will do the first step.
> 
> I don't think TLS 1.3 will see a wide deployment immediately. Sure,
> the
> famous top websites and top browsers will, but enterprises will not.
> And
> especially those with any kind of loggin/auditing requirements cannot
> even allow TLS 1.3 with ephemeral DH on their network.
> 
> I would personally first try and disable TLS 1.0 in f29 and see how
> much
> problems that generates. Then in f30 or f31 disable TLS 1.1.

Except from the internet website statistics the TLS-1.1 only or as
maximum TLS version is not deployed. The sites are either TLS-1.0 max
version or they support also TLS-1.2. So this will not make almost any
difference and the impact on compatibility will be practically the same
as disabling even TLS-1.1.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KTJ64X46W5B37VYDDBV3KNKDRANJU3WA/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Tomas Mraz]

On Tue, 2018-06-12 at 16:01 +0200, Kai Engert wrote:
> On 06/11/18 15:14, Tomas Mraz wrote:
> > > Okay, so IIUC now, this is an all-or-nothing kind of change.  If
> > > I
> > > elect/need to use LEGACY to administer some old hardware that I
> > > cannot
> > > otherwise connect to using the defaults, then I'm compromising
> > > that
> > > host's security for anything/everything its used for until it's
> > > taken
> > > back off LEGACY and returned to whatever the non-LEGACY is
> > > called. 
> > > Do I
> > > have it right now?
> > 
> > Yes, except one thing. Just by switching to LEGACY it does not mean
> > you're compromising the host's security. The protocol negotiation
> > and
> > ciphersuite ordering still applies and it will use the best
> > available
> > protocol and ciphersuite and not some random insecure protocol
> > version
> > and ciphersuite. The insecure protocols and ciphersuites will be
> > used
> > only in the case the other end does not know anything better.
> 
> Could switching to LEGACY allow some man-in-the-middle downgrade
> attacks, in which an attacker manipulates the initial phases of
> handshakes, and tricks the parties to use a weaker protocol?

No, that would be a bug in the implementation or protocol design. But
there should be no such issue with the current implementations.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JOJZOK3N4GL3B6NXIKZKDXJORSHZ7BTZ/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Tomas Mraz]

On Sat, 2018-06-09 at 20:49 -0400, John Florian wrote:
> On 06/08/2018 04:07 AM, Tomas Mraz wrote:
> > On Thu, 2018-06-07 at 16:13 -0400, John Florian wrote:
> > > On 06/07/2018 08:44 AM, Tomas Mraz wrote:
> > > > On Tue, 2018-06-05 at 16:34 -0400, John Florian wrote:
> > > > > On 06/05/2018 12:25 PM, Tomas Mraz wrote:
> > > > > > On Tue, 2018-06-05 at 16:11 +, Christian Stadelmann
> > > > > > wrote:
> > > > > > > "Fallback option" always smells like "protocol downgrade
> > > > > > > attack".
> > > > > > > This would undermine the idea of a crypto policy. Anyway,
> > > > > > > implementing it seems way out of scope for the crypto
> > > > > > > policy.
> > > > > > 
> > > > > > Yes, a fallback option is a no-way. You can switch the
> > > > > > system
> > > > > > policy to
> > > > > > LEGACY, however that does not necessarily mean that some
> > > > > > very
> > > > > > old
> > > > > > legacy HW will start to work with Firefox or another web
> > > > > > browser,
> > > > > > because with newer versions of the browsers and newer
> > > > > > versions
> > > > > > of
> > > > > > TLS/crypto libraries some very old and insecure algorithm
> > > > > > and
> > > > > > protocol
> > > > > > support is being also removed.
> > > > > > 
> > > > > 
> > > > > Makes sense, but what is the best way to deal with such old
> > > > > HW if
> > > > > you're
> > > > > stuck with it?  I don't want to compromise my workstation for
> > > > > all
> > > > > my
> > > > > normal needs just to deal with some ancient embedded https
> > > > > server,
> > > > > but
> > > > > it would kind of suck to have to boot some old live image
> > > > > just to
> > > > > do
> > > > > some routine config change.  It seems the industry has room
> > > > > for
> > > > > improvement here.
> > > > 
> > > > Use a virtual machine with some old live image for such
> > > > insecure
> > > > communication?
> > > > 
> > > > I do not think any "improvement" that involves changing the
> > > > defaults to
> > > > be more lenient even if accompanied with some big warning when
> > > > such
> > > > old
> > > > insecure connection is established would be a good idea. Оnly
> > > > if
> > > > the
> > > > users really have to boot some old live image or do some
> > > > similar
> > > > unpleasant task it will really force the old HW out of
> > > > production
> > > > where
> > > > it should belong. Or we can forget about security based on
> > > > cryptographic protocols altogether.
> > > > 
> > > > Note that we are talking about SSLv2, MD4 or similar long long
> > > > time
> > > > ago
> > > > obsolete stuff. Not things that were just "recently" found as
> > > > insecure.
> > > 
> > > Oh!  I didn't realize the proposal was covering stuff /that/
> > > old. 
> > > Somehow TLS 1.1 just didn't equate in my memory with that era.
> > > Thank
> > > you 
> > > Tomas for the clarification.
> > 
> > No, this is misunderstanding. The change proposal is about newer
> > stuff
> > but the proposal allows for easy revert by setting the crypto
> > policy to
> > LEGACY.
> > 
> > What I was talking in this tread starting with my message from Tue,
> > 05
> > Jun 2018 18:25:57 +0200 was about things that possible very old
> > legacy
> > devices might require for communication that are not present in the
> > TLS
> > libraries anymore.
> > 
> 
> Okay, so IIUC now, this is an all-or-nothing kind of change.  If I
> elect/need to use LEGACY to administer some old hardware that I
> cannot
> otherwise connect to using the defaults, then I'm compromising that
> host's security for anything/everything its used for until it's taken
> back off LEGACY and returned to whatever the non-LEGACY is called. 
> Do I
> have it right now?

Yes, except one thing. Just by swit

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Tomas Mraz]

On Thu, 2018-06-07 at 16:13 -0400, John Florian wrote:
> On 06/07/2018 08:44 AM, Tomas Mraz wrote:
> > On Tue, 2018-06-05 at 16:34 -0400, John Florian wrote:
> > > On 06/05/2018 12:25 PM, Tomas Mraz wrote:
> > > > On Tue, 2018-06-05 at 16:11 +, Christian Stadelmann wrote:
> > > > > "Fallback option" always smells like "protocol downgrade
> > > > > attack".
> > > > > This would undermine the idea of a crypto policy. Anyway,
> > > > > implementing it seems way out of scope for the crypto policy.
> > > > 
> > > > Yes, a fallback option is a no-way. You can switch the system
> > > > policy to
> > > > LEGACY, however that does not necessarily mean that some very
> > > > old
> > > > legacy HW will start to work with Firefox or another web
> > > > browser,
> > > > because with newer versions of the browsers and newer versions
> > > > of
> > > > TLS/crypto libraries some very old and insecure algorithm and
> > > > protocol
> > > > support is being also removed.
> > > > 
> > > 
> > > Makes sense, but what is the best way to deal with such old HW if
> > > you're
> > > stuck with it?  I don't want to compromise my workstation for all
> > > my
> > > normal needs just to deal with some ancient embedded https
> > > server,
> > > but
> > > it would kind of suck to have to boot some old live image just to
> > > do
> > > some routine config change.  It seems the industry has room for
> > > improvement here.
> > 
> > Use a virtual machine with some old live image for such insecure
> > communication?
> > 
> > I do not think any "improvement" that involves changing the
> > defaults to
> > be more lenient even if accompanied with some big warning when such
> > old
> > insecure connection is established would be a good idea. Оnly if
> > the
> > users really have to boot some old live image or do some similar
> > unpleasant task it will really force the old HW out of production
> > where
> > it should belong. Or we can forget about security based on
> > cryptographic protocols altogether.
> > 
> > Note that we are talking about SSLv2, MD4 or similar long long time
> > ago
> > obsolete stuff. Not things that were just "recently" found as
> > insecure.
> 
> Oh!  I didn't realize the proposal was covering stuff /that/ old. 
> Somehow TLS 1.1 just didn't equate in my memory with that era. Thank
> you 
> Tomas for the clarification.

No, this is misunderstanding. The change proposal is about newer stuff
but the proposal allows for easy revert by setting the crypto policy to
LEGACY.

What I was talking in this tread starting with my message from Tue, 05
Jun 2018 18:25:57 +0200 was about things that possible very old legacy
devices might require for communication that are not present in the TLS
libraries anymore.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EUHD4ZM53RHK4AHFANN4LE2LD7XZGUX6/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Tomas Mraz]

On Tue, 2018-06-05 at 16:34 -0400, John Florian wrote:
> On 06/05/2018 12:25 PM, Tomas Mraz wrote:
> > On Tue, 2018-06-05 at 16:11 +, Christian Stadelmann wrote:
> > > "Fallback option" always smells like "protocol downgrade attack".
> > > This would undermine the idea of a crypto policy. Anyway,
> > > implementing it seems way out of scope for the crypto policy.
> > 
> > Yes, a fallback option is a no-way. You can switch the system
> > policy to
> > LEGACY, however that does not necessarily mean that some very old
> > legacy HW will start to work with Firefox or another web browser,
> > because with newer versions of the browsers and newer versions of
> > TLS/crypto libraries some very old and insecure algorithm and
> > protocol
> > support is being also removed.
> > 
> 
> Makes sense, but what is the best way to deal with such old HW if
> you're 
> stuck with it?  I don't want to compromise my workstation for all my 
> normal needs just to deal with some ancient embedded https server,
> but 
> it would kind of suck to have to boot some old live image just to do 
> some routine config change.  It seems the industry has room for 
> improvement here.

Use a virtual machine with some old live image for such insecure
communication?

I do not think any "improvement" that involves changing the defaults to
be more lenient even if accompanied with some big warning when such old
insecure connection is established would be a good idea. Оnly if the
users really have to boot some old live image or do some similar
unpleasant task it will really force the old HW out of production where
it should belong. Or we can forget about security based on
cryptographic protocols altogether.

Note that we are talking about SSLv2, MD4 or similar long long time ago
obsolete stuff. Not things that were just "recently" found as insecure.
-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QJRRPYEIHGADBY3U6I3OPGZD7JY733XV/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Tomas Mraz]

On Wed, 2018-06-06 at 12:05 +, Petr Pisar wrote:
> On 2018-06-05, John Florian  wrote:
> > Makes sense, but what is the best way to deal with such old HW if
> > you're 
> > stuck with it?  I don't want to compromise my workstation for all
> > my 
> > normal needs just to deal with some ancient embedded https server,
> > but 
> > it would kind of suck to have to boot some old live image just to
> > do 
> > some routine config change.  It seems the industry has room for 
> > improvement here.
> 
> Firefox has a white list for domain names:
> security.tls.insecure_fallback_hosts.

I do not think this actually works at all even with the current FF and
Fedora.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TQIQG62DVHQMIVTGTSVEJN2ILC67JN7V/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Tomas Mraz]

On Tue, 2018-06-05 at 11:54 -0500, mcatanz...@gnome.org wrote:
> On Fri, Jun 1, 2018 at 6:40 AM, Jan Kurik  wrote:
> > and weak
> > Diffie-Hellman key exchange sizes (1024 bit)
> 
> What size is currently required by upstream Firefox and Chrome?
> 
> The most recent reference I could find is 
> https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/W
> yGIpevBV1s 
> which suggests they are still using 1024.

Yes, they are using 1024 bits as minimum now.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FY6FMRZPQMSDOSZADTOAIWD4VPXVCANW/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Tomas Mraz]

On Tue, 2018-06-05 at 08:08 -0700, Adam Williamson wrote:
> On Tue, 2018-06-05 at 11:16 +0200, Nikos Mavrogiannopoulos wrote:
> > On Mon, 2018-06-04 at 11:46 -0700, Adam Williamson wrote:
> > > On Fri, 2018-06-01 at 13:40 +0200, Jan Kurik wrote:
> > > > = Proposed System Wide Change: Strong crypto settings: phase 2
> > > > =
> > > > https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
> > > 
> > > 
> > > How about clients for networking with other OSes - e.g. Samba
> > > clients,
> > > and the tools for enrolling systems as Active Directory domain
> > > members?
> > > Do those respect the system policy? If so, have we considered the
> > > impact of these changes on those configurations?
> > 
> > Do these clients use TLS?
> 
> I don't know, but it seems worth considering, and my basic point here
> is this is something the Change owner should be responsible for
> figuring out: making at least a reasonable effort to evaluate which
> important (particularly release-critical) software and workflows will
> be affected by the change and proposing plans for testing them. "we
> should check curl behaves as expected" just doesn't really cut it as
> a
> test plan.

Do we have a list of the release-critical software and functionality?

Of course verifying that all the packages in Fedora still work (in what
sense?) is a quite bit unrealistic requirement.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JODSHUPXNLSEXFFJQBH5EDYGDEAP4CIQ/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Tomas Mraz]

On Tue, 2018-06-05 at 16:11 +, Christian Stadelmann wrote:
> "Fallback option" always smells like "protocol downgrade attack".
> This would undermine the idea of a crypto policy. Anyway,
> implementing it seems way out of scope for the crypto policy.

Yes, a fallback option is a no-way. You can switch the system policy to
LEGACY, however that does not necessarily mean that some very old
legacy HW will start to work with Firefox or another web browser,
because with newer versions of the browsers and newer versions of
TLS/crypto libraries some very old and insecure algorithm and protocol
support is being also removed.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4YGCDHY6W7G66YPP4QIJL23AOXKDNPYF/

Re: how to replace ssl with ssh2 in kqoauth

[Tomas Mraz]

On Fri, 2017-12-01 at 06:40 -0600, Rex Dieter wrote:
> Tomas Mraz wrote:
> 
> > Compat-openssl10-devel will be removed at the latest by Fedora 29
> > and
> > anything that requires it will be no longer buildable.
> 
> That's the first I've seen or heard of any such hard deadline... has
> that 
> been mentioned before?

I was not completely precise with that statement above - this is my
current intention.

The other option is that someone will step up and take over the
maintenance of compat-openssl10 at that point. I'd be willing to
maintain the package after that time only if compat-openssl10-devel is
removed - that means having compat-openssl10 only purely as third party
application backwards compatibility library.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: how to replace ssl with ssh2 in kqoauth

[Tomas Mraz]

On Thu, 2017-11-30 at 13:49 +, Martin Gansser wrote:
> Is it possible to compile kQOAuth [1] with ssh2 by using openssl, as
> it always comes to conflict between compat-openssl10 and openssl. 
> I have already searched in the sources of kqoauth for the places
> where ssl is referenced.
> 
> $ grep -r ssl *
> 
> kqoauthutils.cpp:#include 
> kqoauthutils.cpp:#include 
> kqoauthutils.cpp:#include 
> kqoauthutils.cpp:#include 
> kqoauthutils.h:#include 
> Makefile:LIBS  = $(SUBLIBS) -lssl -lcrypto -lQt5Gui
> -lQt5Network -lQt5Core -lGL -lpthread 
> src.pro:LIBS += -lssl -lcrypto
> 
> i tink it isn't enough only to replace -lssl with -lssh2
> 
> [1] http://pkgs.fedoraproject.org/cgit/rpms/kqoauth-qt5.git/tree/kqoa
> uth-qt5.spec
> 
> Have somebody a idea ?

What you're trying to achieve simply cannot work. OpenSSL (where libssl
is from) and libssh2 have completely different purpose.

If there is a problem with conflict of compat-openssl10 and openssl the
solution is to make the thing that requires compat-openssl10 ported to 
new openssl API and thus make it require openssl.

Compat-openssl10-devel will be removed at the latest by Fedora 29 and
anything that requires it will be no longer buildable.

-- 
Tomáš Mráz
Red Hat

No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

 * Google and NSA associates, this message is none of your business.
 * Please leave it alone, and consider whether your actions are
 * authorized by the contract with Red Hat, or by the US constitution.
 * If you feel you're being encouraged to disregard the limits built
 * into them, remember Edward Snowden and Wikileaks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Heads Up - openssl makefile and scripts for creating self signed certificates

[Tomas Mraz]

On 10/24/2017 04:23 PM, Tomas Mraz wrote:
> I was asked here to merge pull request that moves the openssl makefile
> and scripts for creating self signed certificates to /usr/share/doc.
> 
> I am not sure this is the right thing to do as these are definitely
> still used currently.
> 
> Although it is much easier now to set up proper certificates for your
> servers with Let's Encrypt, it is still not fully automatable process
> (it needs at least some set up at the beginning for the first issued
> certificate). Thus it cannot be included for example in rpm packages
> %post scripts, etc.
> 
> At least I would like to know from maintainers of packages  that depend
> on openssl whether they currently use the makefile or the scripts to
> create self signed certificate for the service.

One more thing to add - the pull request is here:

https://src.fedoraproject.org/rpms/openssl/pull-request/1

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

Heads Up - openssl makefile and scripts for creating self signed certificates

[Tomas Mraz]

I was asked here to merge pull request that moves the openssl makefile
and scripts for creating self signed certificates to /usr/share/doc.

I am not sure this is the right thing to do as these are definitely
still used currently.

Although it is much easier now to set up proper certificates for your
servers with Let's Encrypt, it is still not fully automatable process
(it needs at least some set up at the beginning for the first issued
certificate). Thus it cannot be included for example in rpm packages
%post scripts, etc.

At least I would like to know from maintainers of packages  that depend
on openssl whether they currently use the makefile or the scripts to
create self signed certificate for the service.

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

Re: How should we handle gnupg v1.4.X as gpg1?

[Tomas Mraz]

On Wed, 2017-10-11 at 05:33 +, Christopher wrote:
> On Tue, Oct 10, 2017 at 5:44 PM Dominik 'Rathann' Mierzejewski <
> domi...@greysector.net> wrote:
> 
> > On Tuesday, 10 October 2017 at 20:57, Christopher wrote:
> > > On Tue, Oct 10, 2017 at 1:04 PM Brian C. Lane 
> > > wrote:
> > > 
> > > > The time for change is finally, almost here :) Upstream is
> > > > talking
> > 
> > about
> > > > installing the v1.4 series as gpg1. They have already switched
> > > > the
> > > > default install of 2.2 to /usr/bin/gpg, but we currently
> > > > override this
> > > > with the --enable-gpg-is-gpg2 switch in gnupg2.
> > > > 
> > > > Tracker bug here - https://dev.gnupg.org/T3443
> > > > Discussion -
> > > > https://lists.gnupg.org/pipermail/gnupg-devel/2017-October/0331
> > > > 51.html
> > > > 
> > > > When this happens I plan on tracking upstream's change and
> > > > installing
> > 
> > as
> > > > gpg1, but I'm pretty sure we need a plan so that things don't
> > > > end up
> > 
> > all
> > > > broken.
> > > > 
> > > 
> > > Have you considered using alternatives as part of that plan, with
> > > gpg2
> > 
> > set
> > > to higher priority than gpg1? Since upstream calls both binaries
> > > "gpg",
> > 
> > it
> > > kind of already makes sense to deconflict them with the
> > > alternatives
> > 
> > system
> > > in this way.
> > 
> > Alternatives are for things that are drop-in replacements. As far
> > as I
> > know, gpg2 is not a drop-in replacement for gpg1.
> > 
> 
> I suppose it depends on which characteristics you're considering when
> you
> compare the two. I can't be the only one who has noticed their
> command-line
> usage similarities, which is the characteristic I would expect to
> matter
> when considering using the alternatives system.

I think that the incompatibility of the key storage warrants for not
using the alternatives system in this case.

-- 
Tomáš Mráz
Red Hat

No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

 * Google and NSA associates, this message is none of your business.
 * Please leave it alone, and consider whether your actions are
 * authorized by the contract with Red Hat, or by the US constitution.
 * If you feel you're being encouraged to disregard the limits built
 * into them, remember Edward Snowden and Wikileaks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GnuPG 2.2.0 and replacement of GnuPG1

[Tomas Mraz]

On Sun, 2017-09-03 at 13:45 +0200, Igor Gnatenko wrote:
> GnuPG 2.2.0 has --enable-gpg-is-gpg2 which would install compat
> symlink
>  from /usr/bin/gpg to /usr/bin/gpg2..
> 
> Is it time to retire gnupg (v1) ?

I really do not care. If the gpg v1 is still maintained upstream and
there is somebody willing to maintain the Fedora package, I think we
can keep the situation as is. This does not apply to RHEL/CentOS where
we already ship gpg2 with the compat symlinks.

-- 
Tomáš Mráz
Red Hat

No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

 * Google and NSA associates, this message is none of your business.
 * Please leave it alone, and consider whether your actions are
 * authorized by the contract with Red Hat, or by the US constitution.
 * If you feel you're being encouraged to disregard the limits built
 * into them, remember Edward Snowden and Wikileaks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: tcp_wrappers deprecation

[Tomas Mraz]

On 08/16/2017 11:37 AM, Michal Sekletar wrote:
> On Tue, Aug 15, 2017 at 1:58 PM, Jakub Jelen  wrote:
> 
>>
>> So can we discuss it now once more without the affiliation to systemd?
>> The fact is that we still do not have any other replacement except
>> firewalls. But do we need one?
>>
> 
> IIRC, in the past discussion there was quite a lot of people arguing
> that we actually need one. I personally don't think we as a
> distribution need a drop-in replacement. However, what we possibly
> need, is a migration path for already deployed systems using
> tcp_wrappers. Just dropping tcp_wrappers and potentially leaving
> deployed services completely open would very irresponsible.
> 
> Also we should consider an impact this change will have on our
> downstreams focusing on enterprise use-cases (CentOS, RHEL). I recon
> that "splash damage" potentially caused by this change will be bigger
> there than in Fedora itself.

On the other hand shipping downstream openssh patch adding this support
when there is already similar functionality present in upstream via the
Match directive in sshd_config is something I would definitely not vote for.

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

Re: F27 Self Contained Change: Authselect: new tool to replace authconfig

[Tomas Mraz]

On Tue, 2017-07-18 at 20:30 +0100, Tom Hughes wrote:
> On 18/07/17 15:26, Stephen Gallagher wrote:
> 
> > On Tue, Jul 18, 2017 at 10:17 AM Tom Hughes  > > wrote:
> > 
> > Well none of my newly upgraded F26 machines appear to be
> > running it ;-)
> > 
> > I said "default". So for fresh installs this is the case.
> 
> Yes my laptop, which had been installed with F26, was indeed running
> it.
> 
> It appears that whatever enabled it (anaconda?) did so by manually 
> editing nsswitch.conf however, so running "authconfig --updateall"
> to 
> rebuild the configuration would have disabled it.

That would be most probably authconfig bug, could you please report it,
ideally with steps to reproduce?

The contents of the /etc/nsswitch.conf should have priority over
/etc/sysconfig/authconfig. I already have RFE for authconfig to
basically keep /etc/sysconfig/authconfig only as a hint and diminish
its use. Unfortunately I have not had time to work on that yet.

-- 
Tomáš Mráz
Red Hat

No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

 * Google and NSA associates, this message is none of your business.
 * Please leave it alone, and consider whether your actions are
 * authorized by the contract with Red Hat, or by the US constitution.
 * If you feel you're being encouraged to disregard the limits built
 * into them, remember Edward Snowden and Wikileaks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

How to make a package multilib

[Tomas Mraz]

Hi all,

the package p11-kit-trust needs to be multilib because it contains
PKCS#11 .so object used for access to trusted CA certificate store.
However because this package is a PKCS#11 module and not a regular
shared library there is no p11-kit-trust-devel package which would mark
it automatically as multilib. Is there a way how to mark the package
multilib explicitly? Adding Requires: p11-kit-trust%{?_isa} to another
multilib package apparently did not help.

Regards,
-- 
Tomáš Mráz
Red Hat

No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

 * Google and NSA associates, this message is none of your business.
 * Please leave it alone, and consider whether your actions are
 * authorized by the contract with Red Hat, or by the US constitution.
 * If you feel you're being encouraged to disregard the limits built
 * into them, remember Edward Snowden and Wikileaks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [systemd-devel] Locale setup for non-shells

[Tomas Mraz]

On Mon, 2017-05-22 at 15:45 +0300, Mantas Mikulėnas wrote:
> On Mon, May 22, 2017 at 2:11 PM, Nikolai Kondrashov <
> nikolai.kondras...@redhat.com> wrote:
> 
> > Hi everyone on systemd-devel,
> > 
> > I'm trying to solve a problem of supplying locale settings to non-
> > shell
> > programs acting as login shells in Fedora and RHEL, as described
> > below.
> > 
> > So far it seems the Debian way of doing things will work.
> > 
> > Could you please confirm that the format of locale.conf is not
> > going to
> > change
> > in a way incompatible with what pam_env.so expects?
> > 
> 
> Well, the format of locale.conf is meant to be sourceable by sh/bash,
> so I
> don't expect it to ever change. It's also covered by the official
> "stability promise" [1].
> 
> A better question is what exactly pam_env.so expects... Last time I
> couldn't quite figure out when it wants a key=value file and when it
> wants
> its own special "foo DEFAULT=bar" format, and in fact the manual
> doesn't
> seem to match the actual behavior... Does it autodetect or something?

The 'key=value' format works by accident but I plan to make it official
 one day.

-- 
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: Locale setup for non-shells

[Tomas Mraz]

On Mon, 2017-05-22 at 12:46 +0300, Nikolai Kondrashov wrote:
> Hi Tomas,
> 
> Do you think the below could be done, from PoV of PAM/authconfig?

I do not have any problem with this if the locale.conf file is really
in format that is accepted by pam_env.

> On 04/04/2017 06:06 PM, Nikolai Kondrashov wrote:
> > At the moment users logging into Fedora on a text terminal
> > (console, SSH,
> > etc.) get their locale environment variables (LANG, LC_ALL, etc.)
> > set up by
> > the shell they use. I.e. the shell ultimately sources the
> > /etc/locale.conf
> > file. This works fine in most cases.
> > 
> > However, if the user has his/her "shell" set to any program that is
> > not one of
> > the traditional shells, i.e. it doesn't source any shell profiles,
> > or even
> > doesn't understand any shell language at all, then that program
> > doesn't get
> > locale settings.
> > 
> > Theoretical examples can include captive portals on jump-hosts, or
> > special-purpose systems with dedicated TUI instead of a shell. A
> > practical
> > example that concerns me is a user session recording program [1]
> > which needs
> > to run before user shell, and intercept all I/O going to and from
> > the
> > terminal.
> > 
> > I would like to know if it is possible to change Fedora to provide
> > the locale
> > variables through the environment user "shell" inherits, instead of
> > expecting
> > it to read /etc/locale.conf, which is distro-specific.
> > 
> > This is done in Debian already. During session setup in
> > login/sshd/etc. they
> > use pam_env to read /etc/default/locale. Similar thing is possible
> > to do in
> > Fedora too. E.g. just put this into /etc/pam.d/system-auth:
> > 
> > session required  pam_env.so envfile=/etc/locale.conf
> > 
> > Nick
> > 
> > [1] Tlog - terminal I/O logger
> > https://github.com/Scribery/tlog
-- 
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: Wild changes in nsswitch.conf

[Tomas Mraz]

On Mon, 2017-05-15 at 17:15 +0200, Jakub Hrozek wrote:
> On Mon, May 15, 2017 at 04:35:56PM +0200, Tomas Mraz wrote:
> > My current Fedora 26 default nsswitch.conf contains these lines:
> > 
> > passwd:  sss files systemd
> > shadow: files sss
> > group:   sss files systemd
> > 
> > Not sure which package created this configuration, but:
> > 
> >  * Where is the consistency?
> >  * Where is the Fedora Change page that talks about these
> > modifications
> > of fairly critical systemwide configuration file?
> >  * From which time systemd started to manage user accounts of the
> > machine, again where is the Fedora Change page for such change?
> 
> Is this what you are looking for?
> https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers
> 
> That page says:
> """
> This change proposes leveraging a new "files" provider SSSD will ship
> in
> the next version in order to resolve also users from the local files.
> That way, the "sss" NSS module can be configured before the files
> module
> in nsswitch.conf and the system could leverage sss_nss caching for
> both
> local and remote users. 
> """

The questions still hold for the consistency between passwd and shadow
and also for the systemd module present.

-- 
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

Wild changes in nsswitch.conf

[Tomas Mraz]

My current Fedora 26 default nsswitch.conf contains these lines:

passwd:  sss files systemd
shadow: files sss
group:   sss files systemd

Not sure which package created this configuration, but:

 * Where is the consistency?
 * Where is the Fedora Change page that talks about these modifications
of fairly critical systemwide configuration file?
 * From which time systemd started to manage user accounts of the
machine, again where is the Fedora Change page for such change?

Regards,
-- 
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: switching libcurl back to OpenSSL and providing the libcurl-minimal subpackage

[Tomas Mraz]

On Thu, 2017-04-13 at 10:42 +0100, David Woodhouse wrote:
> On Thu, 2017-04-06 at 12:57 -0400, Stephen Gallagher wrote:
> > > > Also, wasn't there an issue with the OpenSSL's licensing and
> > > > GPL?
> > > > If it still is, could it affect any of the packages that are
> > > > now using
> > > > libcurl?
> > > 
> > > There is this: https://www.openssl.org/blog/blog/2017/03/22/licen
> > > se/
> 
> Which doesn't really help as they're moving to a different but still
> GPL-incompatible licence. Grr :)

GPLv2-only incompatible licence. It is compatible with GPLv3 or GPLv2+.
 So the situation is better and given the objectives for the licence
change they had I am afraid there was no better choice.
-- 
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: upcoming build and release developer flag day December 12 2016

[Tomas Mraz]

On Ne, 2016-11-20 at 18:47 -0600, Michael Catanzaro wrote:
> 
> Well I fixed all my typos except the two in that quote there. :)
> Maybe
> I am a shitty htypist byt yeah I have to use backspace al ot. Somehow
> I
> tnhink the popelo (oh gosh I am doing really badly here) who
> recommend
> passpharess ()this is embarrassing I can't even get the parentheses
> right) are eithre excellent typists, ro not following their own
> advice
+1
I use muscle memory to type passwords and I actually hate long
passphrases as I am not able to type them fast enough without typos. I
could probably type them if I typed them slowly but that isn't
something I am willing to do.

-- 
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: RFC (round 2): Change the default hostname for Fedora 26+

[Tomas Mraz]

On Pá, 2016-11-11 at 13:20 -0500, Stephen Gallagher wrote:
> I think this is extreme overkill for something that doesn't need to
> be
> cryptographically sound. It literally just needs to be eight
> characters with a
> sensible random distribution. I considered using some non-reversible
> transformation of machine-id for this simply because I wanted to
> avoid trying to
> consume any of the entropy in /dev/random since we'd be doing this
> early in the
> installer (when entropy tends to be at a premium). Maybe that was
> overkill and I
> should just pull from /dev/random.

Please, please, do not mention use of /dev/random at all. Use
/dev/urandom.

-- 
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: Storage size unknown on rawhide

[Tomas Mraz]

On 10/25/2016 10:41 AM, Tomasz Torcz wrote:
> On Tue, Oct 25, 2016 at 10:01:55AM +0200, Julien Enselme wrote:
>> Hi,
>>
>> I have an error while building ccnet on rawhide:
>>
>> utils.c: In function 'ccnet_decrypt_with_key':
>> utils.c:1141:20: error: storage size of 'ctx' isn't known
>>  EVP_CIPHER_CTX ctx;
>   Looks like ccnet need porting to OpenSSL 1.1.x API.
> There was a thread about version bump few days ago on this list.

Yes, please look here for similar patches, how this API change needs to
be reflected in the sources:
https://github.com/patch-exchange/openssl-1.1-transition

Basically you have to use EVP_CIPHER_CTX_new() and ..._free() to
allocate and deallocate the structure and use only pointer. For all the
structure members that should be used publicly there are accessor
functions ..._get..() and ..._set...().

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

Re: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On St, 2016-10-12 at 12:40 +0200, Tomas Mraz wrote:
> On St, 2016-10-12 at 10:28 +0200, Vít Ondruch wrote:
> > 
> > But what about stable versions of libraries applications? For
> > example,
> > in current Rawhide, you won't be able to build any stable Ruby
> > version
> > downloaded as tarball without the compat-openssl-devel. And it is
> > question, if upstream will be able to backport the OpenSSL 1.1.0
> > support
> > into stable Ruby versions [1]. Not mentioning all the older Ruby
> > versions which are unsupported, but up until now, you could build
> > them
> > on your own (actually it should be possible to disable the OpenSSL
> > support, but that is not common scenario).
> > 
> > I personally don't care much about this scenario, but I am pretty
> > sure
> > that others might care more 
> Yes, I am getting more and more inclined to ship compat-openssl10-
> devel. However I will make it conflicting with openssl-devel and its
> use for Fedora packages should be strongly discouraged.

So I've added compat-openssl10-devel subpackage to the compat-openssl10 
package. Please use it only in case all of these three conditions are
true:

1. port of your dependent package is not straightforward
2. upstream does not work on the port
3. you are not able to port it yourself

Please also in that case fill a bug against your package and make it
block the FTBFS with OpenSSL1.1.0 tracker bug: https://bugzilla.redhat.
com/show_bug.cgi?id=1383740

If the port should be straightforward (i.e. the package does not
contain language bindings for OpenSSL, it is not an OpenSSL engine, and
it is not using OpenSSL internals deeply) but you do not have time to
work on it, please also fill the FTBFS bug and add me to CC so I can
work on the patch.

-- 
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: libbson soname alias removal

[Tomas Mraz]

On Čt, 2016-10-13 at 14:32 +, Petr Pisar wrote:
> On 2016-10-13, Tom Hughes <t...@compton.nu> wrote:
> > 
> > 
> > In other words, does the soname need to change?
> > 
> The soname did not change. But packages built against older library
> linked to versioned symbols. Thus they had to be rebuild.
> 
> I'm not very verse in version symboling. If you think the removal
> requires bumping soname (technically probably yes because you simply
> cannot run the old executable against the new library), you can try
> to
> explain it to the upstream. At the and it's only a release candidate.
> But be prepared they are quite obstinate about this packaging stuff.

I do not think it is worth it. Effectively rpm dependencies detect this
breakage anyway so there is no need to change the soname.

-- 
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: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On St, 2016-10-12 at 15:33 +0200, Tomas Mraz wrote:
> On St, 2016-10-12 at 14:39 +0200, Kamil Dudka wrote:
> > 
> > On Friday, October 07, 2016 14:49:49 Tomas Mraz wrote:
> > > 
> > > 
> > > Hi all,
> > > 
> > > the openssl will be rebased in Rawhide to 1.1.0 on Monday. There
> > > will
> > > be also 1.0.2 compat package (compat-openssl10) so the
> > > dependencies
> > > are
> > > not broken and Rawhide should be installable. Also things that do
> > > not
> > > depend on openssl should be rebuildable without changes.
> > > 
> > > On the other hand due to the major API changes in 1.1.0 if your
> > > package
> > > uses OpenSSL it will not be possible to rebuild it without
> > > patching.
> > > Some upstreams already updated their code to work with 1.1.0 so
> > > if
> > > it
> > > is your case again there might not be any problems rebuilding it.
> > Is there any migration guide regarding the API changes introduced
> > in
> > 1.1.0?
> Unfortunately not except for what's written here: https://wiki.openss
> l.
> org/index.php/1.1_API_Changes#Major_Changes_so_far
> 
> Basically replacing direct access to structure members with use of
> getters and setters should work. Also of course the structures cannot
> be directly put into variables but allocated/destroyed via *_new
> *_free
> functions.

Also there is https://github.com/patch-exchange/openssl-1.1-transition 
where you can take some inspiration.

-- 
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: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On St, 2016-10-12 at 14:39 +0200, Kamil Dudka wrote:
> On Friday, October 07, 2016 14:49:49 Tomas Mraz wrote:
> > 
> > Hi all,
> > 
> > the openssl will be rebased in Rawhide to 1.1.0 on Monday. There
> > will
> > be also 1.0.2 compat package (compat-openssl10) so the dependencies
> > are
> > not broken and Rawhide should be installable. Also things that do
> > not
> > depend on openssl should be rebuildable without changes.
> > 
> > On the other hand due to the major API changes in 1.1.0 if your
> > package
> > uses OpenSSL it will not be possible to rebuild it without
> > patching.
> > Some upstreams already updated their code to work with 1.1.0 so if
> > it
> > is your case again there might not be any problems rebuilding it.
> Is there any migration guide regarding the API changes introduced in
> 1.1.0?

Unfortunately not except for what's written here: https://wiki.openssl.
org/index.php/1.1_API_Changes#Major_Changes_so_far

Basically replacing direct access to structure members with use of
getters and setters should work. Also of course the structures cannot
be directly put into variables but allocated/destroyed via *_new *_free
functions.

-- 
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: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On St, 2016-10-12 at 10:28 +0200, Vít Ondruch wrote:
> 
> Dne 10.10.2016 v 16:29 Tomas Mraz napsal(a):
> > 
> > On So, 2016-10-08 at 13:37 +0200, Kevin Kofler wrote:
> > > 
> > > Tomas Mraz wrote:
> > > > 
> > > > At worst if the patching of a package is highly non-trivial and
> > > > the
> > > > upstream is not responsive we might have to drop the package
> > > > from
> > > > Fedora.
> > > > 
> > > > We do not want to keep 1.0.2 devel around as that could make it
> > > > to
> > > > look
> > > > like the 1.0.2 is still fully "supported" in Fedora and there
> > > > would
> > > > be
> > > > no incentive to switch to 1.1.0. Also to get any new features
> > > > from
> > > > upstream OpenSSL we have to move to newer versions as they are
> > > > released
> > > > as the old versions get only bug fixes.
> > > IMHO, this is not acceptable. If the API of a library changes
> > > enough
> > > to 
> > > warrant a compat package, you have to provide the -devel for the
> > > compat 
> > > package as well. Dropping all the packages that don't build
> > > against
> > > the new 
> > > incompatible version from Fedora is not a reasonable plan.
> > We will work on porting the dependent packages to the new API. If
> > by
> > some reasonable deadline there are still some packages that are not
> > dead by other reasons and we are unable to port them we can add
> > -devel
> > to the compat package. Note though that small changes in such
> > packages
> > will be needed anyway as the include files of the compat package
> > will
> > have to be in non-default include directory. (If the package
> > doesn't
> > use pkgconfig to find the needed CFLAGS automatically.)
> > 
> But what about stable versions of libraries applications? For
> example,
> in current Rawhide, you won't be able to build any stable Ruby
> version
> downloaded as tarball without the compat-openssl-devel. And it is
> question, if upstream will be able to backport the OpenSSL 1.1.0
> support
> into stable Ruby versions [1]. Not mentioning all the older Ruby
> versions which are unsupported, but up until now, you could build
> them
> on your own (actually it should be possible to disable the OpenSSL
> support, but that is not common scenario).
> 
> I personally don't care much about this scenario, but I am pretty
> sure
> that others might care more 

Yes, I am getting more and more inclined to ship compat-openssl10-
devel. However I will make it conflicting with openssl-devel and its
use for Fedora packages should be strongly discouraged.

-- 
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: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On St, 2016-10-12 at 08:21 +, Petr Pisar wrote:
> On 2016-10-12, Tomas Mraz <tm...@redhat.com> wrote:
> > 
> > On St, 2016-10-12 at 08:22 +0200, Nikos Mavrogiannopoulos wrote:
> > > 
> > > Was the load using dlopen() or simply an indirect link?
> Both Perl modules were dlopened. Each of the module linked to
> different OpenSSL directly (DT_NEEDED).
> 
> > 
> > Also what I would expect to crash is situation where the perl
> > modules
> > linked to different OpenSSL versions try to pass the references to
> > OpenSSL data structures across the versions. That certainly won't
> > work.
> > 
> Yes. It passed pointers to BIGNUM and EC_KEY between them.

Now that surely won't work. But it should not be common scenario except
for language bindings where various modules using openssl are in
separate packages. I do not know if there are any other such languages
than perl. Usually all the bindings are in a single package or at worst
there are two packages - one for libcrypto bindings and one for libssl.

-- 
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: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On St, 2016-10-12 at 08:22 +0200, Nikos Mavrogiannopoulos wrote:
> On Tue, 2016-10-11 at 16:46 +, Petr Pisar wrote:
> > 
> > On 2016-10-11, Remi Collet <fed...@famillecollet.com> wrote:
> > > 
> > > 
> > > It doesn't seem possible to use a compat library (else we will
> > > very
> > > probably going to encounter issues is both library versions are
> > > used in
> > > the same process, because of the numerous libraries linked to PHP
> > > or its
> > > extensions)
> > > 
> > That's true. I was just porting a Perl package to OpenSSL 1.1.0 and
> > while the ported code build and passed all tests when built against
> > old
> > OpenSSL, it crashed when linked to the new OpenSSL. The reason
> > there
> > was another Perl package loaded into the process that was linked to
> > the old OpenSSL.
> Was the load using dlopen() or simply an indirect link?

Also what I would expect to crash is situation where the perl modules
linked to different OpenSSL versions try to pass the references to
OpenSSL data structures across the versions. That certainly won't work.

On the other hand the scenario where one library linked by an
application uses OpenSSL 1.1 for TLS and another library uses OpenSSL
1.0 for SHA256 hashing, should work - at least it worked for me when I
tested it.

-- 
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: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On St, 2016-10-12 at 01:23 +0100, David Woodhouse wrote:
> On Mon, 2016-10-10 at 16:29 +0200, Tomas Mraz wrote:
> > 
> > 
> > We will work on porting the dependent packages to the new API. If
> > by
> > some reasonable deadline there are still some packages that are not
> > dead by other reasons and we are unable to port them we can add
> > -devel
> > to the compat package. Note though that small changes in such
> > packages
> > will be needed anyway as the include files of the compat package
> > will
> > have to be in non-default include directory. (If the package
> > doesn't
> > use pkgconfig to find the needed CFLAGS automatically.)
> Even if it uses pkgconfig, it's still going to need to look for
> openssl102.pc or whatever we call it, because just 'openssl' is going
> to get it OpenSSL 1.1.
> 
> And if we *are* going to ship a separate -devel package for 1.0.2 and
> 1.1 in parallel we are *really* going to need to make sure that
> *neither* of them live in /usr/include/openssl/ where they can be
> picked up by default.

I am against moving 1.1 into separate /usr/include. If we ship the
compat-openssl10-devel I will make it conflict with 1.1.0 openssl-
devel. Of course that won't allow compiling things against both
versions but that is something we do not want to allow anyway.

-- 
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: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On Út, 2016-10-11 at 16:46 +, Petr Pisar wrote:
> On 2016-10-11, Remi Collet <fed...@famillecollet.com> wrote:
> > 
> > It doesn't seem possible to use a compat library (else we will very
> > probably going to encounter issues is both library versions are
> > used in
> > the same process, because of the numerous libraries linked to PHP
> > or its
> > extensions)
> > 
> That's true. I was just porting a Perl package to OpenSSL 1.1.0 and
> while the ported code build and passed all tests when built against
> old
> OpenSSL, it crashed when linked to the new OpenSSL. The reason there
> was
> another Perl package loaded into the process that was linked to the
> old
> OpenSSL.
> 
> Therefore I conclude it will be necessary to rebuild all packages
> requiring the old soname against new OpenSSL in the order of
> dependencies.

In my testing of application that pulled both old (indirectly) and new
OpenSSL (directly), it did not crash and I did not see anything wrong
with it. So it seems not all cases are broken however apparently the
above is reason for moving dependencies to 1.1.0 as quickly as
possible.

-- 
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: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On Út, 2016-10-11 at 15:27 +0200, Igor Gnatenko wrote:
> On Tue, Oct 11, 2016 at 3:21 PM, Vít Ondruch <vondr...@redhat.com>
> wrote:
> > 
> > Just FTR, I opened Ruby upstream ticket asking about the OpenSSL
> > 1.1.0
> > support:
> > 
> > https://bugs.ruby-lang.org/issues/12830
> > 
> > Not sure if you'll have also some Fedora specific tracker 
> Would be nice to get tracking bug created on RHBZ, so we can track
> all
> the packages.

Created:
https://bugzilla.redhat.com/show_bug.cgi?id=1383740

-- 
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: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On Út, 2016-10-11 at 09:25 -0600, Orion Poplawski wrote:
> On 10/07/2016 06:49 AM, Tomas Mraz wrote:
> > 
> > Hi all,
> > 
> > the openssl will be rebased in Rawhide to 1.1.0 on Monday. There
> > will
> > be also 1.0.2 compat package (compat-openssl10) so the dependencies
> > are
> > not broken and Rawhide should be installable. Also things that do
> > not
> > depend on openssl should be rebuildable without changes.
> > 
> > On the other hand due to the major API changes in 1.1.0 if your
> > package
> > uses OpenSSL it will not be possible to rebuild it without
> > patching.
> > Some upstreams already updated their code to work with 1.1.0 so if
> > it
> > is your case again there might not be any problems rebuilding it.
> > 
> > I will be also working on patching and rebuilding the dependencies
> > starting with minimal install and expanding to broader installs of
> > Fedora. However there might be cases where the package is using
> > some
> > obscure features of the old 1.0.x API and the port might be non-
> > trivial 
> > - I do not expect such packages to be common however cooperation
> > with
> > the respective package upstream might be needed in such cases.
> > 
> > At worst if the patching of a package is highly non-trivial and the
> > upstream is not responsive we might have to drop the package from
> > Fedora.
> > 
> > We do not want to keep 1.0.2 devel around as that could make it to
> > look
> > like the 1.0.2 is still fully "supported" in Fedora and there would
> > be
> > no incentive to switch to 1.1.0. Also to get any new features from
> > upstream OpenSSL we have to move to newer versions as they are
> > released
> > as the old versions get only bug fixes.
> > 
> It appears that setting:
> 
> -DOPENSSL_API_COMPAT=0x1002L
> 
> Should at least partially get you the 1.0.2 API.  Although clamav's
> configure
> test for SSL_library_init() doesn't #include  so that doesn't
> work for
> it out of the box.

Yes, it basically works for deprecated functions. However it does not
work for things that access structure members in the 1.0 API.

> Also, getting:
> 
> crypto.c: In function 'cl_load_crl':
> crypto.c:1113:32: error: dereferencing pointer to incomplete type
> 'X509_CRL
> {aka struct X509_crl_st}'
>  tm = cl_ASN1_GetTimeT(x->crl->nextUpdate);
> ^~
> 
> So looks like it doesn't work for all cases.

Yes, all the structures are opaque regardless of OPENSSL_API_COMPAT.

-- 
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: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On So, 2016-10-08 at 13:37 +0200, Kevin Kofler wrote:
> Tomas Mraz wrote:
> > 
> > At worst if the patching of a package is highly non-trivial and the
> > upstream is not responsive we might have to drop the package from
> > Fedora.
> > 
> > We do not want to keep 1.0.2 devel around as that could make it to
> > look
> > like the 1.0.2 is still fully "supported" in Fedora and there would
> > be
> > no incentive to switch to 1.1.0. Also to get any new features from
> > upstream OpenSSL we have to move to newer versions as they are
> > released
> > as the old versions get only bug fixes.
> IMHO, this is not acceptable. If the API of a library changes enough
> to 
> warrant a compat package, you have to provide the -devel for the
> compat 
> package as well. Dropping all the packages that don't build against
> the new 
> incompatible version from Fedora is not a reasonable plan.

We will work on porting the dependent packages to the new API. If by
some reasonable deadline there are still some packages that are not
dead by other reasons and we are unable to port them we can add -devel
to the compat package. Note though that small changes in such packages
will be needed anyway as the include files of the compat package will
have to be in non-default include directory. (If the package doesn't
use pkgconfig to find the needed CFLAGS automatically.)

-- 
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: Weak password madness is back again

[Tomas Mraz]

On Pá, 2016-10-07 at 11:58 -0500, Michael Catanzaro wrote:
> On Fri, 2016-10-07 at 18:07 +0200, Hans de Goede wrote:
> > 
> > Suggested fix if you "shell out to passwd" in g-c-c, then why not
> > also do this in g-i-s presumable you can share the code then and
> > have less security sensitive code to worry about ? When you do
> > make sure you run passwd as root (from g-i-s), not as the newly
> > created user. I can set whatever passwd I want using
> > "passwd " as root just fine.
> We should probably just switch to using accountsservice, which runs
> as
> root, to change the password; it's kind of silly to use passwd
> directly
> "for auditability" if it's possible to change passwords using
> accountsservice instead. accountsservice should be changed to use
> passwd if desired. (Currently accountsservice uses usermod, which is
> I
> guess why we don't use it in g-c-c.) Does that sound OK, Ondrej?
> 
> Then that would solve the problem of getting errors from PAM, and we
> can decide whether to enforce password strength in GNOME based on
> whether the current user is an admin or not (or if he is
> authenticated
> as an admin for editing other accounts... that would be kind of
> confusing, though, if a non-admin user with access to an admin
> password
> gets hit by the password strength policy just because he didn't
> unlock
> the panel with the admin password before changing his password; not
> sure what the UI should be for this).

If accountsservice uses usermod it generates audit events too although
slightly different ones than passwd. But that should not be a problem
for auditability.

-- 
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: Weak password madness is back again

[Tomas Mraz]

On Pá, 2016-10-07 at 15:56 +0200, Hans de Goede wrote:
> Hi,
> 
> So 2 devel cycles ago we had this whole discussion
> about how forcing people to choose strong passwords in anaconda
> was making live hard for testers / test-installs and this
> decision was reverted.
> 
> So now here I'm doing a F25 Fedora ARM test install, end up
> in the gnome-ified first-time-setup wizzard and cannot continue
> until I make my test-user password strong enough. UGH.
> 
> So can we get this fixed please, or do we need to escalate
> this all the way up to FESco again ?

Is that a regression? Previously the discussion was about Anaconda not
about gnome initial setup or whatever is the password dialogue you are
talking about. Not that I am supporter of making it impossible to
override password strength check in any kind of initial setup tools.

The only place where the password strength check should not be
overridable is when a regular user tries to change his own password.

-- 
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

OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

Hi all,

the openssl will be rebased in Rawhide to 1.1.0 on Monday. There will
be also 1.0.2 compat package (compat-openssl10) so the dependencies are
not broken and Rawhide should be installable. Also things that do not
depend on openssl should be rebuildable without changes.

On the other hand due to the major API changes in 1.1.0 if your package
uses OpenSSL it will not be possible to rebuild it without patching.
Some upstreams already updated their code to work with 1.1.0 so if it
is your case again there might not be any problems rebuilding it.

I will be also working on patching and rebuilding the dependencies
starting with minimal install and expanding to broader installs of
Fedora. However there might be cases where the package is using some
obscure features of the old 1.0.x API and the port might be non-trivial 
- I do not expect such packages to be common however cooperation with
the respective package upstream might be needed in such cases.

At worst if the patching of a package is highly non-trivial and the
upstream is not responsive we might have to drop the package from
Fedora.

We do not want to keep 1.0.2 devel around as that could make it to look
like the 1.0.2 is still fully "supported" in Fedora and there would be
no incentive to switch to 1.1.0. Also to get any new features from
upstream OpenSSL we have to move to newer versions as they are released
as the old versions get only bug fixes.

-- 
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

[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 <tho...@redhat.com
<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

[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

[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

[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

[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: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable

[Tomas Mraz]

On Pá, 2016-08-19 at 15:54 +0200, Kai Engert wrote:
> On Fri, 2016-08-19 at 09:45 -0400, Stephen Gallagher wrote:
> > 
> > However, pre-release Fedora is different from released Fedoras in
> > that the
> > updates-testing repo is enabled by default on them. This means that
> > if you
> > push
> > the ca-certificates package to updates-testing before next week's
> > Go/No-Go
> > meeting, it is guaranteed that it will already be available to
> > anyone doing a
> > dnf update from the moment they install the Alpha media. This makes
> > it exactly
> > one update from inclusion on Alpha systems. It does not need to
> > wait for a
> > stable push to get there.
> Thank you for this detail.
> 
> In other words:
> - exclude this change from alpha to avoid all risks
> - create the alpha release, and after it's done:
> - build this change into f25 updates-testing
> - all F25 alpha users doing updates will get this change
>   immediately and will participate in testing it.

+1 to this plan, except for one thing - you do not have to wait for
alpha to be released before you build and create the testing update. It
will not be inadvertently included into the alpha anyway. 

-- 
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
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: OpenSSL-1.1.0 COPR for Rawhide

[Tomas Mraz]

On Pá, 2016-07-22 at 10:24 -0400, Simo Sorce wrote:
> On Fri, 2016-07-22 at 10:21 -0400, Simo Sorce wrote:
> > 
> > On Fri, 2016-07-22 at 17:17 +0300, Antti Järvinen wrote:
> > > 
> > > Tomas Mraz writes:
> > >  > for anybody insterested in testing and/or porting applications
> > > to the
> > >  > new OpenSSL 1.1.0 API I've prepared a COPR repository:
> > > 
> > > Strongly advised, OpenSSL 1.1 API changes slightly compared to
> > > 1.0 and
> > > at least in debian the list of packages not compiling any more
> > > was rather
> > > impressive, see 
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061
> > > and I'd expect something similar in other distributions too.
> > > Mostly
> > > this is head-ache of upstreams but it might be good manners to
> > > file
> > > upstream error tickets early :)
> > Second, I was given a heads up about failing packages by an Ubuntu
> > maintainer of upstream projects of mine, and I had to change every
> > single one of them. I haven't rebuild all of them yet for Fedora
> > either
> > because the changes do not work at run time, I have to wait until
> > Feodra
> > Rawhide gets 1.1.0 anyway.
> > 
> > So please land this as early as possible in Fedora as it will
> > require to
> Actually , given how disruptive this is going to be we may want to
> think
> of creating a separate tag and rebuild the majority of core packages
> that break there and only then tag it at once in rawhide, or rawhide
> user experience will be miserable until all package maintainers get
> around to fix it.

My current plan (might be changed) is to:

1. Fill Fedora Change proposal for Fedora 26 very early.

2. Add compat 1.0.2 package which would be used by 3rd party
applications and also temporarily by applications that are not yet
ported to the new API. However the current plan is to not provide
-devel subpackage for 1.0.2 compat packages so if you needed to rebuild
something on rawhide you would have to fix the build issues with the
new openssl.

The tag should not be strictly necessary and I'd like to avoid it as
rawhide with the compat package should be installable and relatively
usable. Only the developers that use OpenSSL API calls would have to
patch their code.

-- 
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
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

OpenSSL-1.1.0 COPR for Rawhide

[Tomas Mraz]

Hi,

for anybody insterested in testing and/or porting applications to the
new OpenSSL 1.1.0 API I've prepared a COPR repository:

https://copr.fedorainfracloud.org/coprs/tmraz/OpenSSL-1.1.0/

The FIPS patches and system crypto policy patch is not yet ported.

If you find any problems or have any suggestions for improvements,
please mail me directly.
-- 
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
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GPG2 as default /usr/bin/gpg

[Tomas Mraz]

On St, 2016-02-17 at 08:10 -0800, Brian C. Lane wrote:
> On Wed, Feb 17, 2016 at 04:51:48PM +0100, Tomas Mraz wrote:
> > On St, 2016-02-17 at 07:29 -0800, Brian C. Lane wrote:
> > > On Wed, Feb 17, 2016 at 05:52:45AM +, Christopher wrote:
> > > > I just ran into this: https://bugzilla.redhat.com/show_bug.cgi?
> > > > id=1
> > > > 309175
> > > > It's not a huge deal (and there are several workarounds, for
> > > > git
> > > > and for
> > > > other tools which default ot using 'gpg'), but it highlights
> > > > the
> > > > mismatch
> > > > between the default /usr/bin/gpg running gpg1, when other
> > > > tools,
> > > > like
> > > > gpg-agent, are tailored for gpg2.
> > > > 
> > > > RHEL/CentOS has shipped /usr/bin/gpg with gnupg2 since at least
> > > > sometime in
> > > > RHEL6.
> > > 
> > > Which was a mistake, in my opinion.
> > > 
> > > > I'm not saying we shouldn't continue to ship gnupg1, but can we
> > > > at
> > > > least
> > > > rename it, so gnupg package is version 2, and gnupg1 provides
> > > > /usr/bin/gpg1
> > > > instead? This seems overdue. Is there any reason not to do
> > > > this?
> > > 
> > > I am opposed to this. If a tool wants/needs to
> > > use v2 it should be using gpg2 not gpg. gpg v1.4.x is still
> > > active
> > > upstream and is shipped as gpg so we shouldn't be renaming it.
> > 
> > What would be your opinion for using alternatives for the
> > /usr/bin/gpg?
> 
> I'm not sure what you're asking here. We have 2 different binaries
> already. I don't see any reason to add more or rename the existing
> ones.

I meant renaming the gnupg-1 binary to gpg1 and make the /usr/bin/gpg a
symlink to it via the alternatives system so if user install only
gnupg2 the symlink would point to gpg2. But the default can still be a
symlink to gpg1.

-- 
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
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GPG2 as default /usr/bin/gpg

[Tomas Mraz]

On St, 2016-02-17 at 07:29 -0800, Brian C. Lane wrote:
> On Wed, Feb 17, 2016 at 05:52:45AM +, Christopher wrote:
> > I just ran into this: https://bugzilla.redhat.com/show_bug.cgi?id=1
> > 309175
> > It's not a huge deal (and there are several workarounds, for git
> > and for
> > other tools which default ot using 'gpg'), but it highlights the
> > mismatch
> > between the default /usr/bin/gpg running gpg1, when other tools,
> > like
> > gpg-agent, are tailored for gpg2.
> > 
> > RHEL/CentOS has shipped /usr/bin/gpg with gnupg2 since at least
> > sometime in
> > RHEL6.
> 
> Which was a mistake, in my opinion.
> 
> > I'm not saying we shouldn't continue to ship gnupg1, but can we at
> > least
> > rename it, so gnupg package is version 2, and gnupg1 provides
> > /usr/bin/gpg1
> > instead? This seems overdue. Is there any reason not to do this?
> 
> I am opposed to this. If a tool wants/needs to
> use v2 it should be using gpg2 not gpg. gpg v1.4.x is still active
> upstream and is shipped as gpg so we shouldn't be renaming it.

What would be your opinion for using alternatives for the /usr/bin/gpg?

The problem is that now the keystores are incompatible and it creates
big confusion to the users when they see some key in gnupg-1 and do not
see it in gnupg-2 and the other way around.

-- 
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
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GPG2 as default /usr/bin/gpg

[Tomas Mraz]

On St, 2016-02-17 at 05:52 +, Christopher wrote:
> I just ran into this: https://bugzilla.redhat.com/show_bug.cgi?id=130
> 9175
> It's not a huge deal (and there are several workarounds, for git and
> for
> other tools which default ot using 'gpg'), but it highlights the
> mismatch
> between the default /usr/bin/gpg running gpg1, when other tools, like
> gpg-agent, are tailored for gpg2.
> 
> RHEL/CentOS has shipped /usr/bin/gpg with gnupg2 since at least
> sometime in
> RHEL6.
> I'm not saying we shouldn't continue to ship gnupg1, but can we at
> least
> rename it, so gnupg package is version 2, and gnupg1 provides
> /usr/bin/gpg1
> instead? This seems overdue. Is there any reason not to do this?

I am in favor of changing the default too. The question is whether it
is not too late for Fedora 24 as I'd say this should be a Fedora Change
and we are past the deadline for Changes proposals. So this will have
to be postponed to Fedora 25.

-- 
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
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: System CA certificate trust store management meeting

[Tomas Mraz]

On Po, 2016-02-15 at 13:05 +, David Woodhouse wrote:
> On Tue, 2016-02-02 at 17:13 +0100, Tomas Mraz wrote:
> > Hello,
> > for anyone interested in the subject and visiting DevConf in Brno
> > on 
> > this Friday - we will be holding an informal meeting to gather use-
> > cases 
> > for needed improvements in this area. We are interested in feedback
> > from 
> > Fedora/RHEL system administrators and developers.
> > 
> > The meeting will happen on Friday Feb 5th 2016 13:10-14:30 at the 
> > DevConf venue in the room C228.
> > 
> > See also:
> > https://communityblog.fedoraproject.org/system-ca-certificate-trust
> > -management-review-planning-meeting-devconf/
> > 
> > Regards,
> > 
> > Tomas Mraz, Security Technologies Team member at Red Hat
> 
> Hi Tomas,
> 
> Was there a conclusion for this?

Hello,

unfortunately probably due to no mention of the public meetings in the
official DevConf schedule - they were mentioned only on a separate page
in the DevConf brochure - there was only a single non-redhatter that
appeared at the meeting.

We had some informal discussion with him and the redhatters that were
present. The conclusion was that our team should probably focus more on
the crypto libraries support for the stapled extensions and using the
trust store directly via the p11-kit-trust PKCS#11 module and not
through the extracted certificate lists - namely OpenSSL lacks this
support and probably should be the first priority to fix before any
development of high-level trust management application/API should
start.

-- 
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
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

System CA certificate trust store management meeting

[Tomas Mraz]

Hello,
for anyone interested in the subject and visiting DevConf in Brno on 
this Friday - we will be holding an informal meeting to gather use-cases 
for needed improvements in this area. We are interested in feedback from 
Fedora/RHEL system administrators and developers.


The meeting will happen on Friday Feb 5th 2016 13:10-14:30 at the 
DevConf venue in the room C228.


See also:
https://communityblog.fedoraproject.org/system-ca-certificate-trust-management-review-planning-meeting-devconf/

Regards,

Tomas Mraz, Security Technologies Team member at Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Tomas Mraz]

On Út, 2015-12-01 at 11:15 +0100, Tomas Hozza wrote:
> You are not mistaken.
> 
> This is the third time, because previously we rather moved the change to the
> next Fedora to bring better user experience. Every time there was something
> enhanced, since we learned a lot about user use-cases, so this is definitely
> not the same change as before, only the root idea is the same. The Change Wiki
> is up-to-date and contains the current information.
> 
> Also with many projects involved - Gnome Shell, NetworkManager, Unbound,
> dnssec-trigger, SELinux (always a pleasure:), Docker... it is not the easiest
> thing to agree on changes and coordinate everything on time.
> 
> What changed from the top of my head:
> - We decided not to install the dnssec-trigger panel by default and rather
>   better integrate dnssec-trigger with NM and Gnome Shell
> - We decided not to query user for security decisions, and for the beginning
>   if there is no other option just fall back to the current state that that is
>   in Fedora today

Will there be at least some visual indicator that the network you're
connected to does not provide secure DNS?

-- 
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
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Packaging:NamingGuidelines Re: DNF is completly unable to act with local packages

[Tomas Mraz]

On Čt, 2015-11-19 at 20:59 +, Sérgio Basto wrote:
> On Qua, 2015-11-18 at 17:11 -0600, Jason L Tibbitts III wrote:
> > > > > > > "SB" == Sérgio Basto <ser...@serjux.com> writes:
> > 
> > SB> When we fix the .spec and don't change the source, we bump
> > rightmost
> > SB> version, when we change the source, we bump the left version, so
> > we
> > SB> can distinguish when we update the source and when we updated the
> > SB> .spec, this contrast for me is important.
> > 
> > For me, the simple rule that a Release: tag less than 1 implies
> > prerelease software, while a Release: tag of 1 or greater implies a
> > post-release package, is important.  So far the proponents of this
> > change haven't shown what things would actually look like after this
> > change, so it's hard for me to come up with a reason to change my
> > opinion.
> 
> prerelease numbering can't begin with 0 and increased to 0.1 because :
> 
> next version of foo-0.b would be foo-0.1.b and "b">1 

Nope, 1>"b" in rpm version compare.

-- 
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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dealing with the "my packages" problem

[Tomas Mraz]

On Čt, 2015-11-19 at 11:06 +0100, Martin Kolman wrote:
> On Wed, 2015-11-18 at 16:39 -0500, David Airlie wrote:
> > 
> > - Original Message -
> > > From: "Brian C. Lane" <b...@redhat.com>
> > > To: devel@lists.fedoraproject.org
> > > Sent: Thursday, 19 November, 2015 7:05:57 AM
> > > Subject: Re: Dealing with the "my packages" problem
> > > 
> > > On Wed, Nov 18, 2015 at 02:24:37PM -0500, Rob Crittenden wrote:
> > > > Matthew Miller wrote:
> > > > > On Tue, Nov 17, 2015 at 06:08:24PM -0600, Jason L Tibbitts III
> > > > > wrote:
> > > > > > After some IRC discussion I've come to the following
> > > > > > proposal: that
> > > > > > maintainers have some way to easily indicate how open they
> > > > > > are to
> > > > > > external contributions.  Basically this would take the form
> > > > > > of a few
> > > > > > options in pkgdb where maintainers can indicate their
> > > > > > willingness to
> > > > > > have provenpackagers carry out a few actions.  Please read
> > > > > > the github
> > > > > > ticket for details:
> > > > > >   https://github.com/fedora-infra/pkgdb2/issues/274
> > > > > 
> > > > > What if we made the options be about _the package_ rather than
> > > > > about
> > > > > the maintainer's prickliness? Rather than "Please don't touch
> > > > > my
> > > > > package" (I know that's not your wording; added for emphasis)
> > > > > make it
> > > > > "This package has unusual complications; please coordinate any
> > > > > changes
> > > > > with the package maintainers."
> > > > > 
> > > > > Well, except, less wordy. :)
> > > > > 
> > > > > And, in thinking about it, I don't think we should encourage
> > > > > the
> > > > > option of "Don't even ask". If there really _is_ something
> > > > > that's a big
> > > > > deal, the package maintainer can always say no when asked.
> > > > > 
> > > > 
> > > > As one of the complainers about current policy, here are my
> > > > thoughts.
> > > > 
> > > > I appreciate tibbs bringing up the discussion. I'd vote for a
> > > > default
> > > > stance of "Ask first."
> > > 
> > > I don't think we need a technical solution, we just need the people
> > > who
> > > feel the need to modify packages they aren't normally involved with
> > > to
> > > ask first. It doesn't matter how simple or complicated the change
> > > is,
> > > just be polite.
> > 
> > But that doesn't scale.
> I think it can be made to scale - at least in most cases.
> 
> We could have a mechanism that stages the change and notifies the
> maintainer (eq. asks first automatically) and gives him the option to
> apply the change or cancel it & do it properly themselves.
> 
> And if there is no reply from the maintainer, the change will be
> applied automatically after some time (24-48 hours ? could be
> configurable).
> 
> I think this workflow would lessen the burden for both parties 
> involved:
> * less work for proven packagers when "doing it right" 
>   (automatic asking, staging & auto apply)
> * maintainers get always notified automatically, can easily 
>   "ACK" trivial changes or cancel the change and do it properly
>   if needed

Yes, this would be almost perfect. If we can get such staging branches
to be automatically merged or merge canceled by the package owner to
work. It also needs a little cultural change but it should not be a
drastic change. Of course this should not encourage provenpackagers to
hastily produce incorrect changes and just depending on the review of
the owner.

We could also have a branch for regular packagers not provenpackagers
working in similar way but it would not be merged automatically but only
when the owner explicitly say so. You can probably already use private
branches for that but it is missing some automation and official
workflow definition.

-- 
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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Orphaning openct and ctapi-common on Rawhide

[Tomas Mraz]

Hello all,

I've orphaned openct and ctapi-common packages on Rawhide as I do not
use them anymore. If nobody picks them they can be safely retired by the
automated process as nothing seems to depend on them. If you pick them,
please consider mailing me and asking for transfer of the ownership also
for the branched releases.

Regards,
-- 
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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)

[Tomas Mraz]

On Čt, 2015-10-08 at 00:06 +0200, Kevin Kofler wrote:
> Stephen Gallagher wrote:
> > * #1483 Decision on bundling policy in the Fedora Package Collection
> >   (sgallagh, 18:11:40)
> >   * LINK: http://paste.fedoraproject.org/276064/44243383/ is sgallaghs
> > proposal without the critpath distinction  (nirik, 18:43:49)
> >   * AGREED: Adjust the packaging policy as described in
> > http://paste.fedoraproject.org/276064/44243383/ (+5, 3, -1)
> > (sgallagh, 18:57:44)
> >   * ACTION: tibbs|w to inform FPC and work on removing the anti-bundling
> > stuff from the guidelines  (sgallagh, 18:59:17)
> 
> Ewww! :-(
> 
> This opens the door to all kinds of duplication, waste of disk space, waste 
> of RAM, symbol conflicts and unfixed security issues!
> 
> "Thanks" for making Fedora worse!

Yes, it seems the quantity over quality view won. :(
Also the haste with which it was pushed is seriously disappointing.

-- 
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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Tomas Mraz]

On Pá, 2015-10-02 at 13:18 +0200, Vít Ondruch wrote:
> Dne 30.9.2015 v 16:52 Ralf Corsepius napsal(a):
> >
> > Like I've said many times before, I feel Fedora needs a serious
> > vulnerability in a widespread bundled or static library, such that
> > people finally comprehend the harm of bundling.
> 
> This harms Fedora but not the upstream project which bundles. If there
> is discovered security issue in the bundled library, they fix it and
> release new version, they are in users view the good guys who cares
> about security. If we fix the same issue in unbundled library, it is
> invisible for users and at the end they demand updated version of the
> upstream project, since they believe that the issues is not fixed in
> Fedora yet.
> 
> I am afraid that no matter how much education you'd like to apply to
> this issue, you will never reduce it, since honestly, most of the
> development is done on different platforms then Linux, where bundlind of
> various kinds is a norm.
> 
> And TBH, as much as I hate this reduction of anti-budnling requirements,
> I also hate to hear from upstream that they don't wish their SW to be
> included in Fedora, since we break it due to unbundling policies.

This seems like a strong argument for the current case where the
bundling exception is provided by FPC. The question is only whether it
needs to be FPC or some another body. The bundling should be approved
only for projects where upstream is fully active and cares about the
security vulnerabilities in the bundled copies of software well. I am
not sure that this should be evaluated just by the single person who
reviews the package for acceptance in Fedora so I do not like the
current proposal. On the other hand the evaluation should be quick and
the current rules seem to me to be slightly too strict.

-- 
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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Tomas Mraz]

On St, 2015-09-30 at 16:25 +0200, Reindl Harald wrote:
> 
> Am 30.09.2015 um 16:13 schrieb Orion Poplawski:
> > On 09/30/2015 07:45 AM, Fabian Deutsch wrote:
> >> Yes, I also see this as a good compromise.
> >> We then have the ability to at least track bundling.
> >>
> > I'd just like to point out that we have always had the requirement for
> > package that bundled libraries to carry the "Provides: bundled(libname)"
> > metadata.  What's new here is not needing to go through the FPC to get
> > an exception.  Which perhaps leads to people not declaring their
> > packages bundled libraries.
> 
> how do you come to that conclusion?
> 
> people not declaring their bundles and not care about policies did the 
> same before: not declare it and not ask for exceptions - there is a 
> logical flow in "now that i don't need to ask FPC i don't declare it"
> 
> the opposite is more likely: people trying to avoid the FPC burden now 
> can declare it without fearing somebody takes notice and points out a 
> violation

I think that's exactly what was Orion trying to say above although the
wording could be interpreted both ways.

-- 
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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Tomas Mraz]

On 11.9.2015 16:17, Matěj Cepl wrote:

On 2015-09-10, 19:10 GMT, Przemek Klosowski wrote:

The reason for this proposal is relatively simple: we know the
advantages to unbundling, particularly with security and resource-
usage. However, the world's developer community largely *does not
care*. We fought the good fight, we tried to bring people around to
seeing our reasoning and we failed.

I think we should really pause and think about what does the 'does not
care' mindset entail. It's not just the attitude towards bundling: it
extends to security problems, integration issues, and who knows what
other aspect of the product. I concede that it's, as you said, a list of
the same tired arguments---but  they do have a point!  I think it is a
mistake to declare defeat, even if it's nominally only on the specific
issue of bundling.


I don’t know how to say it and looked proud or ignorant, but
after spending many years almost exclusively inside of the free
software movement, I have to admit that the Sturgeon’s Law[1]
did not miss us at all, and ninety percent of all free software
(mine included at the first place) is crap. Most development
practices I can see on GitHub are just absolutely horrible.

Everybody talks here about Freedom, Features, Friends, and
First, but there used to be pride in the Fedora community (and
despite my multiple suggestions it has never made it into The
Big Four keywords; probably nobody found out the way how to make
it into F* word) to Make Things Right. We used to be proud for
the best engineering, and taking a lot of effort to make things
in the proper way even when others (hey, Ubuntu!) just throw out
sometimes horrible crap.

For this I am -1 on this proposal. Yes, there is no way for us
to win over the idiocy, and yes, we will probably have to make
number of exceptions when necessary, but the fight against
entropy should never stop and we should strife to make The Right
Things™ against all odds.


And I am giving Matěj a big +1 for what he wrote here. I completely 
agree with that.


Regards,
Tomas Mraz
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking

[Tomas Mraz]

On Pá, 2015-09-04 at 00:38 -0400, Carlos O'Donell wrote:
> On 08/28/2015 03:23 PM, Josh Stone wrote:
> > I update from nss-3.19.3-1.0.fc22.x86_64 to nss-3.20.0-1.0.fc22.x86_64
> > this morning, and now I get this stderr output:
> > 
> > $ /usr/bin/stap -V >/dev/null
> > /usr/bin/stap: Symbol `SSL_ImplementedCiphers' has different size in
> > shared object, consider re-linking
> > 
> > The message comes from ld.so; that symbol comes from libssl3.so.
> > 
> > Should I be worried about this?  Do we need a rebuild of all
> > nss-dependent packages to clear this message?
> 
> Well, it's an ABI break. If you care about ABI issues then the change
> causing the breakage needs reverting and the broken packages need to
> be rebuilt.

The size of the SSL_ImplementedCiphers array is not part of the public
API so it is not really an ABI break in practice. However ld.so of
course cannot know that. Is there any way to make the message disappear
other than rebuild of the dependent package? I am afraid that
unfortunately not.
-- 
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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 Self Contained Change: Standardized Passphrase Policy

[Tomas Mraz]

On Út, 2015-06-30 at 08:36 -0500, Michael Catanzaro wrote:
  I understand that as a request to write some simple how-to-use 
  document
  for libpwquality and not a request to drop it altogether and use
  instead ... what?
  
  Note also that libpwquality is highly configurable and for things 
  that
  can not be configured currently a configuration can be easily added.
 
 We discussed this a while back in the Workstation WG [1]. We'd be happy
 with libpwquality if we could configure it to allow weaker passwords
 than pwquality.conf currently allows for. This feedback was supposed to
 make it to you, but I'm not sure if that happened; we don't track
 action items as well as we should.
 
 Michael
 
 [1] http://meetbot.fedoraproject.org/fedora-meeting/2015-04
 -01/workstation.2015-04-01-15.00.log.html

If you can open FutureFeature bugzillas against Rawhide libpwquality for
each of the changes needed, it would be really helpful.

-- 
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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 Self Contained Change: Standardized Passphrase Policy

[Tomas Mraz]

On Pá, 2015-06-26 at 14:53 -0600, Kevin Fenzi wrote:
 On Fri, 26 Jun 2015 16:21:02 -0400
 Matthias Clasen mcla...@redhat.com wrote:
 
  But passwords and passphrases are not all the same shape or color -
  the requirements for a password you want to use for ssh login over the
  internet are quite different from ones for a shared account used by
  all family members, or a passphrase that you use to protect your
  diary in your home directory.
  
  How does a single common policy make sense for such wildly different
  use cases ?
  
  Your list of applications looks like you are really only interested in
  passwords for local user accounts, though. If that is the case, please
  make that clear in the description.

Yes, I agree with Matthias, that we should be concerned about local user
accounts in this change because different uses of passwords (or
passphrases) have different requirements for strength.

 Side note: IMHO, we should remove and stop using the term
 'password'. It evokes back to the early days of UNIX where you had to
 choose a 8 character or less 'word' to gain access to something. All
 our tools can and should use much longer phrases. 

There is nothing particularly wrong with passwords and multiple word
passphrases are not particularly better. It really depends on situation
and on the particular password or passphrase chosen.

  
   * libpwquality - doesn't set passwords, but should be used in
   common for quality checking in a consistent manner. 
  
  All of the applications that you are listing are already using
  libpwquality, which has not really helped to move us to a consistent
  user experience in this area. We should evaluate if libpwquality is
  really suitable for what we need here. 
 
 Well, I think there's some confusion on how to actually use
 libpwquality. There are basically no docs and I think it's being used
 different ways in different cases. But yes, if it doesn't meet needs we
 could look at alternatives. I am hopeful we can better use it or adjust
 it and keep using it, but we will see. 

I understand that as a request to write some simple how-to-use document
for libpwquality and not a request to drop it altogether and use
instead ... what?

Note also that libpwquality is highly configurable and for things that
can not be configured currently a configuration can be easily added.

That means that libpwquality can be used for various passwords, not only
for the system accounts. You can simply create and set different
configuration files for different password uses.

-- 
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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Harden_all_packages_with_position-independent_code + guile modules

[Tomas Mraz]

On 19.3.2015 08:16, Nikos Mavrogiannopoulos wrote:

On Wed, 2015-03-18 at 11:37 -0700, Moez Roy wrote:

FULL RELRO
http://tk-blog.blogspot.co.at/2009/02/relro-not-so-well-known-memory.html

If that's all we got I suggest to remove this flag or (better) provide a
way for applications that use modules to compile themselves, without
removing the whole set of hardening flags.


Any advise from the change owners? How should applications that use
modules with undefined systems should handle that? Should they add %
undefine _hardened_build by default?

I was doing some research last night but not tested it yet:
nonow
1) add -nonow to the CFLAGS
2) or add -z nonow to the LDFLAGS
doing the koji builds now to test and see if it works.
Also need to test if there is a -lazy option.

Why are you using -Wl,--no-add-needed in the LD flags?


I don't see the reason for it. Added Tomas (the previous maintainer) in
case he remembers.


If I remember correctly it was added to get rid of some unneeded 
dependency that was otherwise pulled in. But it might be unnecessary 
now. You could try to build the rpm (without hardening) with and without 
the -Wl,--no-add-needed and see whether there are some additional 
Requires added to the resulting rpms.


Regards,
Tomas
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: OpenSSL MD5 verification disabled?

[Tomas Mraz]

On 17.3.2015 17:00, Richard Shaw wrote:

I've got a new BZ report for my package TrustedQSL which uses OpenSSL to
very a certificate used for uploading ham radio contacts to an online
logbook. The system uses MD5 which appears to be disabled in F21+.

https://bugzilla.redhat.com/show_bug.cgi?id=1202157

I don't like the workaround specified in the BZ but I don't see an
alternative so I would like to get some input from others who are better
versed in how OpenSSL works.


Hi,
there is no other workaround. And they should not use MD5 signed 
certificates - they are insecure.


Regards,
Tomas Mraz

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Headsup: Xorg is broken in F-22 when used with fips or /etc/system-fips

[Tomas Mraz]

On Út, 2015-02-24 at 10:42 +0100, Hans de Goede wrote:
 Hi all,
 
 Debugging this took me ages, so I thought I would share this with you,
 with the new gdm on wayland landed in F-22 recently Xorg gets started
 as a regular user.
 
 This is a good thing as we want to move to Xorg running as a regular user,
 but we're not 100% there yet, so currently Xorg is still suid-root, and
 needs those root rights to function properly.
 
 But when fips is enabled either on the kernel commandline or a 
 /etc/system-fips
 file exists one of the libraries X is using is dropping the root rights at
 early library init and things fail.
 
 So if X is not working for you all of a sudden, make sure you do not have
 fips enabled on the kernel commandline, and remove any /etc/system-fips
 file you may have.

This is unintended side-effect of running the FIPS selftest in the
libgcrypt constructor, we need to fix that. Please open a new bug
against libgcrypt so the bug fix is tracked.

-- 
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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: DNF as default package manager

[Tomas Mraz]

On St, 2015-01-21 at 11:13 +, Peter Robinson wrote:

 The onus in Fedora has _ALWAYS_ been to prove that the new feature is
 complete and ready to replace the existing working solution, not for
 everyone else to prove that it's not. Given the number of issues I see
 reported with dnf regarding dependencies, current kernels being
 removed and other such issues I've seen nothing to prove it's
 ready Sorry!

That is unfortunately blatantly false statement. There were multiple
features (or what should be called features but formally was not) that
were forced into Fedora even though they weren't by any means finished.
I can name UsrMove, TMPonTMPFS, etc. Even the systemd replacement of
sysvinit change but that was not that bad.

-- 
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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: echoping - Re: Hundreds of bugzilla mails on one day

[Tomas Mraz]

On So, 2015-01-10 at 12:54 +0100, Michael Schwendt wrote:
 Big *sigh*.
 
 Guys, this is not funny anymore. Almost as if some people at Fedora try to
 test how long one can keep one's temper. Well, this is embarrasing and not
 casting a positive light on the Fedora Project package collection:
 
   https://bugzilla.redhat.com/460557
   Package and software are in a desolate state
 
   Reported: 2008-08-28 11:58:50 EDT
 
   No response in bugzilla.
 
   http://koji.fedoraproject.org/koji/buildinfo?buildID=555956
 
   Not updated since F14.

I would just open a FESCo ticket to get the package removed from Fedora.

-- 
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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Abotu setting 'PermitRootLogin=no' in sshd_config

[Tomas Mraz]

- Original Message -
 On Wed, Nov 26, 2014 at 11:48 AM, Scott Schmit i.g...@comcast.net wrote:
  On Tue, Nov 25, 2014 at 09:56:59AM -0500, Simo Sorce wrote:
  On Sat, 22 Nov 2014 08:24:32 + (UTC) P J P wrote:
On Saturday, 22 November 2014 1:39 AM, Richard W.M. Jones wrote:
On Fri, Nov 21, 2014 at 09:11:51AM +0100, Florian Weimer wrote:
The latter.  We have to install authorized_keys inside the VM
anyway, so we can touch sshd_config, too.
   
Virt-builder has a new '--ssh-inject' feature (in F22 only).
   
  $ virt-builder fedora-20 --ssh-inject root
   
would inject your current ssh key into the root account of the new
VM. There are other variations, including ways to create a non-root
user account, see:
   
http://libguestfs.org/virt-builder.1.html
  
 Excellent! :)
  
   So far the consensus seem that it is okay to reverse the current
   default and set PermitRootLogin=no. I'll talk to the upstream
   maintainer - plautrba(https://fedoraproject.org/wiki/User:Plautrba).
  
   Thank you.
 
  We can install machine w/o user accounts, removing the ability to log
  in as root via ssh means those machines will not be accessible.
 
  If you want to remove root access that should be conditionally done at
  firstboot only if a user account was created.
 
  It seems to me that we could tweak this somewhat: only if a user
  account was created OR remote users have been configured
 
 And in months that start with the letter q, but not odd numbed
 weekdays, and if I ate a tuna fish sandwich for lunch, but not if I'm
 wearing white socks, and only on alternate years with a prime number,
 etc, etc., etc.
 
 Look, this is a basic system configuration. It's not Cripple Mr.
 Onion. Pick *one* setting, and let people know from that whether
 they'll need to manipulate their local environments for their
 particular subtle needs.
 
 And for those who don't read Terry Pratchett stories,
 http://discworld.wikia.com/wiki/Cripple_Mr_Onion

Exactly! The more I think about this Change the more I am having an
opinion that we should reject it altogether. In fact this change does not
really bring any real security improvement because for the Workstation
the sshd is already disabled completely by default and for the other products
the people who are installing them can be expected to know what they
are doing.

Also disabling root access does not improve security against targeted attacks
because in such cases the user name can be quite easily inferred. So basically
this feature is just a 'marketing' improvement and not worth the hassle.

Tomas Mraz
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Schedule for Wednesday's FESCo meeting (2014-11-26 at 18UTC)

[Tomas Mraz]

- Original Message -
 On Wed, Nov 26, 2014 at 6:32 AM, Jaroslav Reznik jrez...@redhat.com wrote:
  - Original Message -
  Following is the list of topics that will be discussed in the FESCo
  meeting tomorrow at 18:00UTC in #fedora-meeting on
  irc.freenode.net.
 
  Links to all tickets below can be found at:
  https://fedorahosted.org/fesco/report/9
 
  = Followups =
 
  #topic ticket #1349   Fedora 22 scheduling strategy (and beyond)
  .fesco 1349
 
  Unfortunately, I won't be available today for FESCo meeting. Let me know
  in the ticket.
 
 I am also unable to attend.

And me too.

Regards,
Tomas Mraz
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Summary/Minutes from today's FESCo Meeting (2014-11-19)

[Tomas Mraz]

===
#fedora-meeting: FESCO (2014-11-19)
===

Meeting started by t8m at 18:08:14 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2014-11-19/fesco.2014-11-19-18.08.log.html
.

Meeting summary
---
* init process  (t8m, 18:08:27)

* #1273 Policy interpretation on proprietary products in gnome-software,
  gnome overview search results  (t8m, 18:11:53)
  * The web apps are clearly marked we can close the ticket  (t8m,
18:13:49)

* #1265 Fedora Plasma Product  (t8m, 18:15:03)
  * Closing the ticket as the new product proposals should be presented
to Fedora Council  (t8m, 18:20:41)

* #1326 change to fesco replacement process?  (t8m, 18:21:37)
  * we will revisit this after F21 is released  (t8m, 18:27:26)

* #1359 Automatic OpenH264 download by Firefox  (t8m, 18:28:36)
  * LINK: https://fedorahosted.org/fesco/ticket/1359#comment:26 looks
like a possible long term solution  (kalev, 18:30:24)
  * AGREED: Close the ticket and ask interested parties to work with
legal on more user friendly solution (+7, -0, 0:0)  (t8m, 18:47:07)

* #1367 Please define package manager expectations  (t8m, 18:48:27)
  * AGREED: post to devel list asking for interested parties to improve
http://dnf.readthedocs.org/en/latest/cli_vs_yum.html and revisit
change in the f22 cycle to see if there's any critical gaps (+6, -0,
0:0)  (t8m, 19:07:09)
  * ACTION: nirik will post to the devel list  (t8m, 19:08:20)

* #1368 How to deal with F21 broken dependencies  (t8m, 19:08:56)
  * AGREED: FESCo agrees to dropping the packages with broken
dependencies listed in #1368 from both F21 and rawhide (+7, -0, 0:0)
(t8m, 19:25:56)
  * AGREED: We will do the broken deps cleanup on Final Freeze from now
on in the future Fedora releases (+8, -0, 0:0)  (t8m, 19:30:41)
  * There will be warning sent to the affected maintainers at least 3
weeks in advance  (t8m, 19:31:36)

* #1369 packages should disable internal crash handlers and depend on
  ABRT  (t8m, 19:32:44)
  * Decision postponed to next week  (t8m, 19:57:36)

* Next week chair  (t8m, 19:57:40)
  * ACTION: nirik will chair the next week meeting  (t8m, 19:59:10)

* Open floor  (t8m, 19:59:18)

Meeting ended at 20:01:44 UTC.


Action Items

* nirik will post to the devel list
* nirik will chair the next week meeting


Action Items, by person
---
* nirik
  * nirik will post to the devel list
  * nirik will chair the next week meeting
* **UNASSIGNED**
  * (none)


People Present (lines said)
---
* t8m (100)
* nirik (73)
* mitr (58)
* kalev (50)
* dgilmore (33)
* thozza (32)
* mattdm (31)
* jwb (31)
* sgallagh (27)
* zodbot (15)
* randomuser (13)
* cschalle_ (13)
* sharkcz (12)
* jzeleny (8)
* oddshocks (4)
* kushal (3)
* scollier (2)
* mjg59 (1)
* mmaslano (0)
* stickster (0)


---
18:08:14 t8m #startmeeting FESCO (2014-11-19)
18:08:15 zodbot Meeting started Wed Nov 19 18:08:14 2014 UTC.  The chair is 
t8m. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:08:15 zodbot Useful Commands: #action #agreed #halp #info #idea #link 
#topic.
18:08:19 t8m #meetingname fesco
18:08:19 zodbot The meeting name has been set to 'fesco'
18:08:22 t8m #chair dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh 
stickster t8m thozza
18:08:23 zodbot Current chairs: dgilmore jwb kalev mattdm mitr mmaslano nirik 
sgallagh stickster t8m thozza
18:08:27 t8m #topic init process
18:08:27 nirik .hello kevin
18:08:28 zodbot nirik: kevin 'Kevin Fenzi' ke...@scrye.com
18:08:31 sgallagh .hello sgallagh
18:08:32 zodbot sgallagh: sgallagh 'Stephen Gallagher' sgall...@redhat.com
18:08:38 t8m Hi all I apologize again
18:09:00 thozza .hello thozza
18:09:01 zodbot thozza: thozza 'Tomas Hozza' tho...@redhat.com
18:09:04 mattdm t8m we'll just have to talk fast to make up for it :)
18:09:07 * mattdm is here
18:09:16 dgilmore hi
18:09:33 jwb hi
18:09:34 sgallagh mattdm: lts jst skp vwls fr spd
18:10:37 kalev hi
18:11:30 t8m OK, so let's finally start
18:11:53 t8m #topic #1273 Policy interpretation on proprietary products in 
gnome-software, gnome overview search results
18:12:04 t8m .fesco 1273
18:12:09 zodbot t8m: #1273 (Policy interpretation on proprietary products in 
gnome-software, gnome overview search results) – FESCo - 
https://fedorahosted.org/fesco/ticket/1273
18:13:07 nirik I think this is done and can be closed.
18:13:08 t8m So it seems we can close this ticket because the marking of Web 
apps was accepted upstream and is in Fedora if I understand this correctly
18:13:16 nirik the apps are marked pretty clearly now.
18:13:21 mattdm yeah, exactly.
18:13:26 t8m OK
18:13:35 mattdm there are some other issues but I don't think they are fesco 
issues
18:13:49 t8m #info The web apps are clearly marked we can close the ticket
18:13:53 t8m next topic
18:13:55 randomuser I'm generally in agreement, but I don't like 

Schedule for Wednesday's FESCo Meeting (2014-11-19)

[Tomas Mraz]

Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2014-11-19 18:00 UTC'


Links to all tickets below can be found at: 
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #1273 Policy interpretation on proprietary products in gnome-software, 
gnome overview search results
.fesco 1273
https://fedorahosted.org/fesco/ticket/1273

#topic #1265 Fedora Plasma Product
.fesco 1265
https://fedorahosted.org/fesco/ticket/1265

#topic #1326 change to fesco replacement process?
.fesco 1326
https://fedorahosted.org/fesco/ticket/1326

#topic #1359 Automatic OpenH264 download by Firefox
.fesco 1359
https://fedorahosted.org/fesco/ticket/1359

= New business =

#topic #1367 Please define package manager expectations
.fesco 1367
https://fedorahosted.org/fesco/ticket/1367

#topic #1368 How to deal with F21 broken dependencies
.fesco 1368
https://fedorahosted.org/fesco/ticket/1368

#topic #1369 packages should disable internal crash handlers and depend on ABRT
.fesco 1369
https://fedorahosted.org/fesco/ticket/1369

= Open Floor = 

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 

-- 
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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct