Re: Change of cronie and crontabs CIS compliance

[Nikos Mavrogiannopoulos]

On Wed, Dec 6, 2023 at 1:19 PM Daniel P. Berrangé  wrote:
>
> On Wed, Dec 06, 2023 at 11:16:44AM +0100, Ondrej Pohorelsky wrote:
> > Hi everyone,
> >
> > For F40 I would like to change file permissions of few files that are
> > provided by cronie and crontabs and swap deny list for allow list. I'm not
> > really sure if I should make a change proposal. I figured I'll send an
> > email first and see the feedback.
> >
> > The driving force of this change is feedback from RHEL customers, that they
> > would like to have cronie and crontabs CIS compliant out of the box. Which
> > means changing some of the file permissions and swapping `cron.deny` for
> > `cron.allow`. As it stands now, they have to run their own scripts or dnf
> > plugin (post-transaction-actions) to ensure that each update doesn't
> > overwrite the file permissions they manually set.
>
> This CIS compliance problem is not something that is limited to cron. Their
> list of hardening steps covers a wide variety of software. IOW, even if cron
> were changed, presuambly such customers will need need their own scripts /
> dnf plugin to fix all the other apps listed in the CIS compliance guide.
>
> IOW, I feel like the real question here is whether the distro *as a whole*,
> not cron, wants/needs to be CIS compliant out of the box, or whether it
> should be explicitly an admin deployment task to enable compliance via a
> plugin / script.
>
> I understand some organizations have no choice in whether or not they
> comply with the CIS guidance - its mandated for many. At the same time
> though some of the recommendations, including those for cron, are verging
> on snakeoil / extreme paranoia, and as such are dubious to impose on
> every users of the distro by default.

I think you set the right question there. With the cybersecurity
regulatory trend on EU and US, almost all organizations need to comply
with a secure configuration / hardening scheme like CIS. The main
reason is that if you want to follow any respectable security path
that puts the org on the due care set, you need to ensure that your
systems are configured securely, meaning no more options than the
necessary are enabled on the system. The CIS benchmarks provide that.

Now applying the benchmark can be pretty complex as some of the rules
CIS prohibits are required by some organizations because they run
(e.g.) on the cloud that requires it, but others on a different
environment do not. The question you set is, to the point and useful.
Even if the default installation doesn't follow CIS closely, but
provides a better balance of usability and security based on the CIS
guidelines, it will add value to Fedora derivatives -both by reducing
the default attack surface and by making the more advanced hardening
easier-.

Regards,
Nikos
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

[Nikos Mavrogiannopoulos]

Assuming the goal is to improve fedora, that would be pointless as
telemetry rarely produces useful results as opt-in. It makes sense to have
it opt-out, but I'd expect the telemetry output and inputs to be open and
available for fedora developers.

Regards,
Nikos


On Thu, Jul 6, 2023 at 8:19 PM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> On 06/07/2023 18:10, Aoife Moloney wrote:
> > The Red Hat Display Systems Team (which develops the desktop) proposes
> > to enable limited data collection of anonymous Fedora Workstation
> > usage metrics.
>
> All telemetry collection MUST be an opt-in feature (disabled by
> default). I'm strongly against enabling it by default.
>
> Please add the ability to completely get rid of it by removing the
> telemetry collector package.
>
> --
> Sincerely,
>Vitaly Zaitsev (vit...@easycoding.org)
> ___
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

default network attack surface, networkmanager stands out

[Nikos Mavrogiannopoulos]

Hi,
 I've been looking at Fedora's default --after installation-- attack
surface in terms of servers running, and I see chrony, and
NetworkManager running. NetworkManager runs as root, while chrony runs
as a dedicated user. NetworkManager according to lsof listens at the
bootpc and dhcpv6-client ports and is a pretty interesting setup.

The reason it is interesting is that when I upgrade chrony it restarts
(due to %systemd_postun_with_restart), but I do not see something
similar in NetworkManager. Meaning on a critical vulnerability that
affects the DHCP client paths of networkmanager all fedora systems
remain vulnerable even after installing the updated packages until
they reboot. Is there a particular reason network-manager or at least
its dhcp portion does not restart on upgade, or did I miss something
while looking at it?

Regards,
Nikos
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: systemd-resolved in a container

[Nikos Mavrogiannopoulos]

On Wed, Nov 18, 2020 at 2:23 PM Alexander Bokovoy  wrote:
>
> On ke, 18 marras 2020, Nikos Mavrogiannopoulos wrote:
> >Hi,
> > I realized my fedora-based containers have an /etc/resolv.conf which
> >claims it is managed by resolved, and nsswitch.conf has "resolve" in
> >hosts. However, doing something like
> ># systemd-resolve  --status
> >
> >results to:
> >sd_bus_open_system: No such file or directory
> >
> >Trying to start dbus claims that systemd is not the init:
> ># systemctl start dbus
> >System has not been booted with systemd as init system (PID 1). Can't 
> >operate.
> >Failed to connect to bus: Host is down
> >
> >
> >Is there a way to use systemd resolved in a container?
>
> I figured this out yesterday -- at least in Rawhide, dbus-daemon is now
> replaced by dbus-broker which is not active by default.
>
> So you need
>
>   systemctl enable --now dbus-broker
>
> Without it even hostnamectl doesn't work, not just systemd-resolve.

Is that on the "default" fedora container, or do you use something
else? On fedora33 I get the same message about dbus and systemd not
being pid 1.

regards,
Nikos
___
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: systemd-resolved in a container

[Nikos Mavrogiannopoulos]

On Wed, Nov 18, 2020 at 6:37 PM Paul Wouters  wrote:
>
> On Wed, 18 Nov 2020, Alexander Bokovoy wrote:
>
> >> Is there a way to use systemd resolved in a container?
> >
> > I figured this out yesterday -- at least in Rawhide, dbus-daemon is now
> > replaced by dbus-broker which is not active by default.
> >
> > So you need
> >
> > systemctl enable --now dbus-broker
> >
> > Without it even hostnamectl doesn't work, not just systemd-resolve.
>
> What is the advantage of running systemd-resolved in a container?

I do not know, but as I said the fedora container is set up with it
already there. What I am actually trying to do is to test the resolved
support in an application via the gitlab CI.

regards,
Nikos
___
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

systemd-resolved in a container

[Nikos Mavrogiannopoulos]

Hi,
 I realized my fedora-based containers have an /etc/resolv.conf which
claims it is managed by resolved, and nsswitch.conf has "resolve" in
hosts. However, doing something like
# systemd-resolve  --status

results to:
sd_bus_open_system: No such file or directory

Trying to start dbus claims that systemd is not the init:
# systemctl start dbus
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down


Is there a way to use systemd resolved in a container?

regards,
Nikos
___
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: pcscd and xrdp issue

[Nikos Mavrogiannopoulos]

On Mon, Oct 12, 2020 at 3:55 PM Nikos Mavrogiannopoulos  wrote:

> > Second thing to chance: just ask, if a usable hw is found. Asking 
> > permission for an impossible task is the definition of madnes
> >
> > Back to your request to change the policy:
> >
> > I don't see any restrictions for remote access.  ( F33 has same as 
> > https://pastebin.com/Mn8mzjVp )
> >
> > auth_admin
> > auth_admin
> > yes
> >
> > and I have no clue, besides setting those above to "no", which had the 
> > hoped result(tested), how to change the file to ignore or skip the request 
> > it generates via polkit when gnome starts.But I'm pretty sure, changing the 
> > policy file, just makes thing unusable in case a smartcardread is really 
> > available in the system.
>
> Try setting the access daemon part from auth_admin to yes. Does it
> address the issue?

btw. Have you tried that on the systems that fail? Does it improve the
usability?

regards,
Nikos
___
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: pcscd and xrdp issue

[Nikos Mavrogiannopoulos]

On Fri, Oct 9, 2020 at 4:16 PM Marius Schwarz  wrote:
>
> Am 09.10.20 um 13:18 schrieb Nikos Mavrogiannopoulos:
>
> LIBCCID_ifdLogLevel=0x000F pcscd --foreground --debug --apdu
> --color | tee log.txt
>
> This the unchanged output:

> 00492770 [140407774111296] auth.c:137:IsClientAuthorized() Process 33529 
> (user: 1001) is NOT authorized for action: access_pcsc

^^^
What's this process? (you'll need to figure in your current system)


> Main-problem with it: ABORT just loops to the same requester again and again, 
> resulting in an endless loop
> First thing to change to pcscd, accept an abort for what it is and don't ask 
> again.
> That would solve the major problem, still anoying, but at least it doesn't 
> stop the session login.

What you see is not coming from pcscd. This is a polkit dialog you are
seeing because the process above in your system decided to do some
actions on smart cards. pcscd has no way to know whether that's a new
or a repeating request.

> Second thing to chance: just ask, if a usable hw is found. Asking permission 
> for an impossible task is the definition of madnes
>
> Back to your request to change the policy:
>
> I don't see any restrictions for remote access.  ( F33 has same as 
> https://pastebin.com/Mn8mzjVp )
>
> auth_admin
> auth_admin
> yes
>
> and I have no clue, besides setting those above to "no", which had the hoped 
> result(tested), how to change the file to ignore or skip the request it 
> generates via polkit when gnome starts.But I'm pretty sure, changing the 
> policy file, just makes thing unusable in case a smartcardread is really 
> available in the system.

Try setting the access daemon part from auth_admin to yes. Does it
address the issue?

> As all the opensc tools supplied just return "No smart card readers found.", 
> an invoke of the accessrequest should only be made, if a smartcard is really 
> accessed and not everytime someone logs in.
> And from what i can see on the net, you're the man who knows the answeres ;)

Unfortunately I don't :)

regards,
Nikos
___
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: pcscd and xrdp issue

[Nikos Mavrogiannopoulos]

/usr/share/polkit-1/actions/org.debian.pcsc-lite.policyOn Thu, Oct 8,
2020 at 11:06 AM Marius Schwarz  wrote:
>
> Hi,
>
> this is a topic since a lot of time and it's still hits the user in it's
> face for no reason.
>
> Found: while presenting Fedora 33 changes to an audience and
> screenrecording with wayland isn't working yet :(
>
> Tested on Fedora 33 liveimage:
>
> su
> dnf install xrdp  -y
> adduser -s /bin/bash -d /home/rdptest rdptest
> passwd rdptest
> systemctl start xrdp
>
> ## different pc ##
>
> Start Remmina or XFreeRDP to connect to your running liveimage.
>
> You get a fucking uncloseable requester once the gnome session is open,
> that you need to enter a password for the LIVEUSER with to buttons
> without any function. It's not possible to get rid of it by using either
> one of the buttons nor a windowclose.

I do not have two systems to reproduce, but it seems that something
tries to access the smart cards while you connect and polkit makes
this popup. You can fix it by disabling the popup at all
(/usr/share/polkit-1/actions/org.debian.pcsc-lite.policy), or better,
identify what tried to access the smart cards. Running pcscd with
debug output may help. To do that disable pcscd (systemctl stop and
disable), and then try running it in the foreground:
sudo LIBCCID_ifdLogLevel=0x000F pcscd --foreground --debug --apdu
--color | tee log.txt


> Only Solution: dnf erase pcsc*
>
> Because: stopping that service does not stop the requester from popping
> up, as the daemon gets restarted via a socket.

Yes, the idea is for it to be enabled only when some service asks for
smart card access. I wonder however what is there that requests that
access.

> Now what really makes it so anoying: there is no smartcard reader in the
> hw.

There are two access control levels, access the pcsc daemon, and
access specific cards. Currently according to the pcsc-lite.policy we
ship we require authentication to access either when connecting
remotely. I wonder whether it makes sense to tweak these settings.
Could you try playing with the policy and see whether there are
options that could remove this popup? If you allow access to the
daemon from remote sessions do you still get the popup?

regards,
Nikos
___
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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Nikos Mavrogiannopoulos]

On Tue, Sep 29, 2020 at 3:43 PM Lennart Poettering  wrote:
>
> On Di, 29.09.20 04:03, John M. Harris Jr (joh...@splentity.com) wrote:
>
> > > Search domains on VPNs are an indicator that these domains are handled
> > > by the VPN, that's why we use them also as routing domains. But this
> > > doesn't mean it's the *only* routing domains we use. We use the ones
> > > you configure, primarily. But since the concept didn't previously exist
> > > we make the best from what we have.
> >
> > If you really must send DNS queries to both (which defeats the purpose of
> > 'Split DNS'), then it may be better to just use the DNS server of the VPN 
> > when
> > connected to VPN, then only check the LAN interface when the response is
> > NXDOMAIN.
>
> As mentioned in this thread already: this policy makes sense for some
> cases but not for others.
>
> For example, if I have my laptop in my home wifi, connected to RH VPN,
> then there are some names resolvable only via the local
> DNS. Specifically: my router's, my printer's and my NAS' address. And
> there are other names only resolvable via RH VPN. systemd-resolved for
> the first time gives me a chance for this to just work: it will send
> requests to both the RH DNS servers and the local ones, and uses the
> first successful reply, or the last failed reply. And that's quite
> frankly awesome, because that *never* worked before.
>
> So sending the requests to all available DNS servers in absence of
> better routing info is a great enabler: it makes DNS "just work" for
> many cases, including my own, and I doubt it's a particularly exotic
> one.

It is not an exotic one, but this behavior was in the past considered
a vulnerability (information disclosure) [0]. Are we re-introducing
it? I guess yes, and it can be that the benefits of it outweigh the
vulnerability, but we should be explicit about it in our release
notes.

[0]. CVE-2018-1000135 https://bugzilla.redhat.com/show_bug.cgi?id=1558238

>
> Key, take-away here:
>
> 1. Ideally we'd just route company DNS traffic to VPN, and everything
>else to local LAN DNS. But that requires explicit routing info to
>be configured, we cannot auto-detect this info (beyond some minor
>inference from the search domains)

Do we know which fedora shipped VPNs work well with split-dns and
which will lead to leaking the web sites accessed?

regards,
Nikos
___
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 - ssh clients - drop of PubkeyAcceptedKeyTypes=ssh-rsa

[Nikos Mavrogiannopoulos]

On Tue, Sep 22, 2020 at 8:40 AM Pavel Raiskup  wrote:

> > I hit that two week ago for bitbucket and other servers. In my case I got it
> > connecting to lyx git server. At the time I wrote about it in the 
> > fedora-test
> > mailing list.
> >
> > My workaround solution was to add to ~/.ssh/config
> >
> > Host *
> >   PubkeyAcceptedKeyTypes +rsa-sha2-256,rsa-sha2-512
>
> Tomáš, is this an expected feature or a bug in F33?  What are servers like
> BitBucket expected to do to comply with F33 clients?

Yes it is a feature of Fedora 33. It requires services to use better
algorithms than SHA-1 which is considered broken today. This is
described in the changes that Tomas is driving at:
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2

In this particular case I believe you have identified a bug in
bitbucket's ssh setup. They are using old SSH infrastructure that can
only do SHA-1. You may want to contact them about this.

regards,
Nikos
___
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: Can we use emulation of other architectures to run integration tests?

[Nikos Mavrogiannopoulos]

On Thu, Jul 30, 2020 at 12:25 PM Aleksandra Fedorova  wrote:
>
> Hi, all,
>
> I'd like to get some understanding on the current state of emulation
> of other architectures.
>
> In the current CI infra we have infinite(*) access to x86_64 compute
> resources, but we haven't yet got our hands on any non x86_64
> hardware.
>
> As COPR has recently got support for s390 builds, the question is: if
> emulation is good enough for building packages, can we use it for
> testing? What are the limitations there? Is it worth it?

Few years ago we transformed the gnutls' upstream CI from baremetal
h/w to qemu-user [0] (reasoning was pretty much what you mention, we
had x86-64 systems for free, and we had to pay for everything else).
This eliminated the need for such dedicated hardware, and in practice
the years it was in use I believe it eliminated issues in
compatibility with non-x86-64 architectures  and also helped catch
problems in new code (such as alignment issues). For an upstream test
suite it was totally worth it, and I believe it eliminated all issues
we were getting with non-x86 hardware support. The only drawback that
was noticed is that it could not be used to test some special features
of these CPUs, but that's also a problem with dedicated hardware
(e.g., when it doesn't support the particular instruction set you'd
like to introduce).

regards,
Nikos

[0]. https://gitlab.com/gnutls/gnutls/-/blob/master/.gitlab-ci.yml#L718
___
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

orphaned nuttcp

[Nikos Mavrogiannopoulos]

Hi,
 I've orphaned the nuttcp component. It is long time since I last used
it, and I do not plan updating it again. If you like networking tools
this may be a package for you!

regards,
Nikos
___
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: Is 50+ RPM Subpackages too extreme?

[Nikos Mavrogiannopoulos]

On Wed, Nov 27, 2019 at 4:46 AM Sam Varshavchik  wrote:
>
> Chris writes:
>
> > Hi guys,
> >
> >
> > I just wanted to poll you for some advice.  My notification tool I maintain
> > supports more than 50+ services now, but the only package isolation I do
>
> You should really count the number of texlive subpackages…

I think that from the user perspective that's the best example of what
to avoid when packaging in Fedora.

regards,
Nikos
___
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

[EPEL-devel] Re: libssh2 issues in EPEL8 buildroot

[Nikos Mavrogiannopoulos]

On Wed, Aug 14, 2019 at 10:01 PM Orion Poplawski  wrote:
> My zabbix40 build for epel8 failed:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=37041678
[...]
> The other odd thing is that I cannot install libssh2-devel on my RHEL8 vm
> because it does not appear to exist:

It does not. It is not included in the core crypto libraries. From the
SSH libs only libssh is:
https://access.redhat.com/articles/3655361#which-are-the-rhel-core-crypto-components-2

If the application has an option to compile with libssh, try that one.

regards,
Nikos
___
epel-devel mailing list -- epel-de...@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-de...@lists.fedoraproject.org

Re: nettle: heads up soname bump

[Nikos Mavrogiannopoulos]

On Tue, 2019-07-16 at 06:37 -0400, Nico Kadel-Garcia wrote:
> On Tue, Jul 16, 2019 at 5:34 AM Björn 'besser82' Esser
>  wrote:
> > Am Dienstag, den 16.07.2019, 00:20 +0200 schrieb Kevin Kofler:
> > > Miro Hrončok wrote:
> > > > gnutls now cannot be rebuilt:
> > > > 
> > > > nothing provides libnettle.so.6 needed by gnutls-3.6.8-
> > > > 1.fc31.armv7hl
> > > 
> > > Don't you love circular dependencies?
> > > 
> > > This is really the biggest issue that we have: There are more and
> > > more
> > > circular dependencies. Each of them is a major PITA when trying
> > > to
> > > upgrade a
> > > library.
> 
> The common workaround is to provide a compatibility library for a
> limited period, with very careful handling of "Provides" and
> "Obsoletes" and "Conlicts" until the discrepancy is resolved. This
> has
> happened with gcc multiple times.

That makes sense when one needs to keep the old version because (1) the
new API is incompatible and applications need time to update, or (2)
the ABI compatibility must be retained across releases. We didn't care
about either in this update (we have API-compatibile release), so
indeed, if the tooling could handle such issues as it was suggested it
would save lots of work. Kudos to Daiki who handled the issues that
arised.

regards,
Nikos

___
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

nettle: heads up soname bump

[Nikos Mavrogiannopoulos]

Hi,
 The latest nettle (3.5.1) update will break ABI on rawhide. The API
remains the same hence recompilation will be sufficient to address any
issues.

regards,
Nikos

___
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: rpmlint warning: crypto-policy-non-compliance-gnutls-1

[Nikos Mavrogiannopoulos]

On Mon, May 27, 2019 at 3:00 PM Tomas Mraz  wrote:
>
> 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.

It looks good to me. The rpmlint shouldn't have warned there however.
It seems that it incorrectly checks for SYSLOG string instead of
SYSTEM.
https://src.fedoraproject.org/rpms/rpmlint/blob/master/f/rpmlint.config#_475

regards,
Nikos
___
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?

[Nikos Mavrogiannopoulos]

On Wed, Apr 24, 2019 at 12:24 PM Lennart Poettering
 wrote:
> > > But why do that in userspace at all? the "Trust CPU RNG" kernel
> > > compile time option shows that these things are trivial to solve if
> > > people just want to. Instead of involving rngd at all, why not add a
> > > similar option for the TPM RNG (or any other non-CPU hw rng) and then
> > > rngd doesn't do anything useful anymore whatsoever? I mean, to my
> > > knowledge all those other RNGs already feed into the pool anyway, they
> > > just don't get trusted and thus don't add to the entropy
> > > estimate. Fixing that should be quite doable and given that
> > > CONFIG_RANDOM_TRUST_CPU exists now it shouldn't be politically too
> > > hard to argue for a CONFIG_RANDOM_TRUST_TPM either...
> >
> > I like the part that this is trivial to solve if people want to.
> > Making people agree is an order of magnitude harder than fixing any
> > code. Nevertheless, without rngd, getrandom() would block in one of
> > the first services started by systemd (if it doesn't block in systemd
> > itself).
>
> 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.

regards,
Nikos
___
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?

[Nikos Mavrogiannopoulos]

On Thu, Apr 18, 2019 at 10:23 AM Lennart Poettering
 wrote:
> Sure, you can invoke rngd before systemd, in which case it would have
> to be able to run as PID 1 itself pretty much and then hand over
> things.
>
> But why do that in userspace at all? the "Trust CPU RNG" kernel
> compile time option shows that these things are trivial to solve if
> people just want to. Instead of involving rngd at all, why not add a
> similar option for the TPM RNG (or any other non-CPU hw rng) and then
> rngd doesn't do anything useful anymore whatsoever? I mean, to my
> knowledge all those other RNGs already feed into the pool anyway, they
> just don't get trusted and thus don't add to the entropy
> estimate. Fixing that should be quite doable and given that
> CONFIG_RANDOM_TRUST_CPU exists now it shouldn't be politically too
> hard to argue for a CONFIG_RANDOM_TRUST_TPM either...

I like the part that this is trivial to solve if people want to.
Making people agree is an order of magnitude harder than fixing any
code. Nevertheless, without rngd, getrandom() would block in one of
the first services started by systemd (if it doesn't block in systemd
itself). The kernel option CONFIG_RANDOM_TRUST_CPU, is not portable so
you'll need something more for non-x86. What rngd does that the kernel
doesn't is a jitter entropy "subsystem" which will feed the kernel
with random data, even when the hardware doesn't support something
native.

Can the jitter entropy gather be done by the kernel? It seems yes via
the jitterentropy_rng module. So a combo of CONFIG_RANDOM_TRUST_CPU
and the jitterentropy_rng may help in simplifying fedora (if people
agree :).

regards,
Nikos
___
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: F30 Self-Contained Change proposal: krb5 crypto modernization

[Nikos Mavrogiannopoulos]

On Fri, 2018-12-21 at 15:35 -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/krb5_crypto_modernization
> 
> krb5 will be removing support for DES, 3DES, crc-32, and MD4
> entirely;
> they will not be allowed in session keys or long-term keys.
> Additionally, RC4 and MD5 will be marked deprecated and dangerous.
> 
> == Owner ==
> * Name: [[|Robbie Harwood]]
> * Email: rharwood at fp dot o
> 
> == Detailed Description ==
> 
> For formal deprecation announcements, there have been two
> RFCs.  First
> was [https://tools.ietf.org/html/rfc6649 rfc6649], which deprecated
> single-DES (and export strength RC4).  More recently, there has also
> been [https://tools.ietf.org/html/rfc8429 rfc8429] which deprecated
> the rest of RC4 as well as 3DES.  (Note that 3DES was paired with
> SHA1, RC4 with MD5, and DES with MD4, MD5, or crc32, and that these
> were the only usages of these digests in krb5's Kerberos
> implementation.)
> 
> Of particular note, single-DES has been known-bad since the mid 90s.
> It's now so bad that it can be entirely broken in 13 hours for $300:
> [https://crack.sh/kerb5/ https://crack.sh/kerb5/]  But even though
> other encryption types in this list are less bad, none are what we'd
> call good - especially since krb5 supports much stronger encryption,
> such as AES256/SHA2.
> 
> Finally, field data suggests that complete removal is preferable to
> disabling by default.  Admins have unfortunately been using
> `allow_weak_crypto` (which restored disabled-by-default single-DES
> functionality to krb5) to this day.  A mere config setting doesn't
> suffice to convey how bad this is, nor does it indicate the
> appropriate level of urgency of migration.  For that reason, and in
> anticipation that our crypto backends might one day also remove these
> algorithms, we are going straight to removal as well, rather than
> repeating `allow_weak_crypto` or similar.
> 
> Unfortunately, it's not possible for RC4 to be removed entirely at
> this time because it is still in demand for Active Directory
> integration (which also affects freeIPA and samba).  For this reason,
> it's moved to `allow_weak_crypto`.
> 
> == Benefit to Fedora ==
> 
> Improved crpytography is good for security.  Fedora will be leading
> on
> this change; no other distributions or OS releases have limited the
> bad ciphers that Kerberos can use.
> 
> == Scope ==
> * Proposal owners: rharwood
> * Other developers: N/A (not a System Wide Change)
> * Release engineering: [https://pagure.io/releng/issue/8012 #8012]
> * Policies and guidelines: N/A (not a System Wide Change)
> * Trademark approval: N/A (not needed for this Change)
> 
> == Upgrade/compatibility impact ==
> Users of RC4 who need to continue doing so will need to add
> `allow_weak_crypto = True` to /etc/krb5.conf.
> 
> == How To Test ==
> 
> If you'd like to test either this change or your site's readiness for
> more modern cryptography, that's great!  `krb5.conf(5)` has several
> encryption type (enctype) -related settings  - of particular note is
> permitted_enctypes.  Set to only removed enctyptes to verify they
> don't work anymore; set to only modern enctypes to verify that you're
> ready.  (Then just perform your normal tasks with krb5, such as
> `kinit`).
> 
> C-friendly users might wish to take a look at t_enctypes.c in the
> krb5
> source tree.  (How this will be affected depends on how the removal
> work internally, which I haven't worked out yet.)


Hi,
 How does this ties with crypto policies? libkrb5 is already under
crypto policies and has these ciphers disabled by default. Is this
change about removing them from the code or removing them from the
capabilities of the KDC which is not covered by crypto policies?


> == User Experience ==
> 
> Ideally no change!  Worst case some users will see krb5 produce error
> messages about bad enctypes not being able to be used (has no
> enctype,
> could not fullfill enctype, etc.).  These pains are the feeling of
> the
> world grinding forward security-wise.

I guess there will be different experience in client side where these
are already disabled by default in fedora, and in server side which
they are not.

regards,
Nikos

___
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

new maintainer needed: vpnc-script

[Nikos Mavrogiannopoulos]

Hi,
 I'm the main contact point for vpnc-script (used by vpnc and
openconnect VPN), however I no longer spend time in maintaining it. 

If someone would like to pick it up, please let me know. The main
outstanding issue on that package is:
https://bugzilla.redhat.com/show_bug.cgi?id=1648108

Upstream (David Woodhouse) is responsive and very friendly.

regards,
Nikos

___
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: Unannounced SONAME bump for libssh

[Nikos Mavrogiannopoulos]

On Fri, 2018-08-17 at 08:19 -0500, Michael Cronenworth wrote:
> The libssh package uses wildcards on SONAME version. The package was
> upgraded from 
> 0.7.5 to 0.8.1 in Fedora 27+ that included a SONAME bump.
> 
> Please remove the wildcard in libssh and begin package rebuilds.
> Stable versions of 
> Fedora now contain broken software as the package has been released
> to stable.

It is not really a so-name bump, but rather a replacing of a now-defunc 
library. As far as I understand it should be addressed by:

https://bodhi.fedoraproject.org/updates/FEDORA-2018-4794ce5b1f

regards,
Nikos

___
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/VQETWMZQD42H4GDDC7CAYEJQZZVXWE22/

Re: Making Fedora secure - Package exit policy for security

[Nikos Mavrogiannopoulos]

On Thu, 2018-08-02 at 10:49 +0100, Daniel P. Berrangé wrote:

> > > 
> > > Thank you Huzaifa for bringing that up. I have a talk on fedora
> > > and
> > > crypto in flock, and my recommendation will be towards having
> > > some
> > > process to remove old packages from fedora. CVEs were not the
> > > drivers
> > > there, but the continuous expansion of the crypto core which at
> > > the end
> > > as you say causes CVEs which no-one addresses. To add to that, we
> > > ship
> > > several packages which are the result of an internship, thesis,
> > > packages which are there just in case and all expand the attack
> > > surface.
> > > 
> > > So yes, I'd support something like that, and even further than
> > > that, if
> > > there is no update (upstream release) for 5 years, the
> > > package+dependencies is marked for removal as well. Cancelling
> > > that
> > > process would have to go through a fedora committee.
> > > 
> > 
> > Thank you very much for supporting me on this. This proposal has
> > come
> > after years of experience in dealing with Security in Red Hat,
> > upstream
> > and Fedora itself. Honestly the volume of pkgs in Fedora is
> > disturbing,
> > more disturbing are fly-by maintainers, who do packaging for
> > university
> > projects etc and then disappear :(
> 
> The majority of stuff on the big list of CVEs looks like mainstream
> software, that has been present in Fedora for a long time, with long
> term maintainers. The kind of packages added as side-effect of
> academic
> projects by fly-by maintainers are likely fairly niche use cases, or
> they would have been already added to Fedora. IOW, I don't think fly-
> by
> maintainers are the big problem in our CVE/security handling story
> here.

It makes sense but I don't entirely agree. Indeed for these cases we do
not have CVEs because most likely no-one is checking these special use
cases. We have several insecure crypto libs, several apps that
implement their own crypto that would surprise most of us.

So my point is that reducing vulnerabilities is the goal here, and CVEs
is only one metric of them.

regards,
Nikos

___
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/HVQ25MPBKWQ2KAS5VCBVZUW533ARVQDZ/

Re: Making Fedora secure - Package exit policy for security

[Nikos Mavrogiannopoulos]

On Tue, 2018-07-31 at 09:09 +0530, Huzaifa Sidhpurwala wrote:
> Hi All,
> 
> I was asked to bring this issue[1] to the developer community before
> FESCO makes a decision.
> 
> In several instances[2] there exists packages in Fedora, in which
> package-maintainers did not patch security issues, for multiple
> reasons
> including 1. non-responsive maintainer 2. issue hard to patch 3. no
> one
> cares?
> 
> This is a risk for the distribution, our users and community as a
> whole
> and not to mentioned bad PR :)
> 
> I would like to propose the following:
> 
> 
> 1. If a CRITICAL or IMPORTANT security issue is open against a
> package
> in Fedora-X and by the time X is EOL and the issue is not addressed,
> proactively remove the package from X+1
> 2. If a MODERATE or LOW security issue is open against a package in
> Fedora -X and by the time X+! is EOL, the issue is not addressed,
> remove
> it from X+2
> 
> Note:
> 1. Once pkg is patches, it can be rebuild and re-introduced into the
> distro
> 2. X/X+1 is the best boundary to remove the insecure packages imo,
> since
> inbetween removals are not possible due to the way mirrors work.
> 3. Maintain a list somewhere (automated maybe) of the list of
> packages
> removed and why.
> 4. Have a list of critical pkg, which cannot be removed which will
> break
> the distro.
> 
> The above is not set in stone, but is open for discussion. Let me
> know
> what you guys think!
> 
> In the end, i would like you leave you all with this parting link:
> 

Thank you Huzaifa for bringing that up. I have a talk on fedora and
crypto in flock, and my recommendation will be towards having some
process to remove old packages from fedora. CVEs were not the drivers
there, but the continuous expansion of the crypto core which at the end
as you say causes CVEs which no-one addresses. To add to that, we ship
several packages which are the result of an internship, thesis,
packages which are there just in case and all expand the attack
surface.

So yes, I'd support something like that, and even further than that, if
there is no update (upstream release) for 5 years, the
package+dependencies is marked for removal as well. Cancelling that
process would have to go through a fedora committee.

regards,
Nikos

___
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/JR7UNQKX2BSXNTGRSDRKWYDUA3U46V5I/

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

[Nikos Mavrogiannopoulos]

On Wed, 2018-06-06 at 09:45 -0500, mcatanz...@gnome.org wrote:
> On Wed, Jun 6, 2018 at 4:39 AM, Nikos Mavrogiannopoulos 
>  wrote:
> > I am actually very curious about the results of such a move, and
> > know
> > whether it is going to have a significant impact today. Debian has
> > already tried experimenting with it:
> > 
> > https://lists.debian.org/debian-devel/2017/08/msg00166.html
> 
> But OpenSSL is not used by browsers.

That's right. In that case they would most likely have to handle issues
like, tool A and B don't work with that server, though it works in
firefox. The fedora proposal has a different challenge, if something
doesn't work it wouldn't work anywhere.

> > 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.
> 
> You previously said in this thread that the system policy *will* be 
> used by browsers.

Right, the plan is to have a policy to be default for everyone,
including browsers which run in the OS.

> I would not be concerned if we had a separate policy that was
> suitable 
> for use by browsers, which could be used by Firefox, glib-
> networking, etc. But we don't, and it's not proposed here.

That's correct. I don't think it makes sense to have separate policies
per application.

regards,
Nikos
___
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/7ZWS3GTBB7IA6OG2SCMSCJLN2IYR6FFN/

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

[Nikos Mavrogiannopoulos]

On Tue, 2018-06-05 at 11:41 -0500, mcatanz...@gnome.org wrote:
> On Tue, Jun 5, 2018 at 4:14 AM, Nikos Mavrogiannopoulos 
>  wrote:
> > Note that this change, if applied, includes browsers shipped by
> > fedora
> > (i.e., firefox). That is pretty much all or nothing plan, either we
> > bump the defaults for all software, or for none.
> 
> Nikos, I'm really surprised to see you commenting here without
> saying anything for or against the change.
> Surely this will break a large number of websites?

I am actually very curious about the results of such a move, and know
whether it is going to have a significant impact today. Debian has
already tried experimenting with it:

https://lists.debian.org/debian-devel/2017/08/msg00166.html

> And, if not, then surely we should be able to first convince
> upstream 
> Firefox and Chrome to drop support for TLS 1.0 and 1.1? I would not 
> have any objections if these upstreams were to take the step first.
> Yet that seems extremely unlikely.

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.

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.

regards,
Nikos
___
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/DG6SUTE6PJIJ5PYLUM6ZSMEHFTO2SSO3/

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

[Nikos Mavrogiannopoulos]

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, 

Isn't this what we are actually doing to fedora? We keep options which
we know they are insecure in the default settings to achieve
compatibility. This change is about switching to secure mode by
default.

regards,
Nikos
___
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/JRLMUVA7DDDYWATWMQHMX2VSIP4F6GKB/

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

[Nikos Mavrogiannopoulos]

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?

___
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/ZGHNNM2KKFXIKSXA5ZEQVTKBDCD5F6SZ/

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

[Nikos Mavrogiannopoulos]

On Fri, 2018-06-01 at 10:25 -0500, mcatanz...@gnome.org wrote:
> On Fri, Jun 1, 2018 at 8:06 AM, Daniel P. Berrangé 
>  wrote:
> > What is the availibility of TLS 1.2 vs 1.1/1.0 on the internet ?
> > ie how likely is this to break the ability of users to access
> > websites
> > they care about ?
> 
> Yeah... this has been discussed on this list before. If this change
> is 
> made, then we will need to drop our glib-networking patch that
> causes 
> glib-networking to respect Fedora's system crypto policy, since we 
> simply cannot afford to be more restrictive than major browsers.

Note that this change, if applied, includes browsers shipped by fedora
(i.e., firefox). That is pretty much all or nothing plan, either we
bump the defaults for all software, or for none.

regards,
Nikos
___
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/FQYOX5LB2E4NENAHO3A2XOTPY4FBM3YK/

starting services in fedora

[Nikos Mavrogiannopoulos]

In [0] it was reported that after installation of pcsc-lite in Fedora,
no smart cards were functioning at the system. After rebooting Fedora
everything was functioning as expected.

The issue is that the pcsc daemon uses a socket-activated unit
which is installed by dnf, but not started (and hence the windows-
reminding behavior).

The text on our default services [1] mentions that a service is
"enabled by default on package installation" though there is a 
distinction between 'enable' and 'start'.

The reason behind that is probably summarized in [2]:
> Why don't we start the service after installation?
>Installations can be in changeroots, in an installer context, or 
> in other situations where you don't want the services started.

which is understandable, but does not necessarily lead to good user
experience in Fedora. Zbigniew made a good summary of what needs to be
done for that to work [3].

What do you think overall, is that something that makes sense to
address in general, or in socket activated services only, or not at
all?

regards,
Nikos

[0]. https://bugzilla.redhat.com/show_bug.cgi?id=1545027

[1].
https://fedoraproject.org/wiki/Packaging:DefaultServices

[2]. https://fedoraproject.org/wiki/EPEL:SysVInitScripts?rd=Packaging:S
ysVInitScript#Why_don.27t_we

[3]. https://bugzilla.redhat.com/show_bug.cgi?id=1545027#c29
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [RFC] Replace glibc's libcrypt with libxcrypt for Fedora 29/30

[Nikos Mavrogiannopoulos]

On Wed, 2017-11-08 at 18:08 +0100, Björn 'besser82' Esser wrote:
> Hello everyone,
> 
> since there has been some discussion in the last time about removing
> libcrypt from glibc in some time [1,2,3,4] and splitting it out into
> a
> separate project which can evolve quicker, I'd like to hear your
> oppinion about replacing glibc's libcrypt with libxcrypt [5] for
> Fedora
> 29 (or 30).

A bit late, but thank you for driving that effort! It was time to move
to a better crypt lib.

> Anyways, before this can happen, there is still some work to be done
> with libxcrypt, like adding a FIPS mode or FIPS compliance in a
> different way.

I agree with Florian's comment on that.

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

Re: fedora28 and strong crypto settings

[Nikos Mavrogiannopoulos]

On Mon, 2018-02-26 at 10:26 -0600, mcatanz...@gnome.org wrote:
> On Mon, Feb 26, 2018 at 9:37 AM, Nikos Mavrogiannopoulos 
> <n...@redhat.com> wrote:
> > regarding the strong crypto change in Fedora28 [0], we have
> > identified
> > few (usually internal) sites which break under firefox or other
> > tools.
> > The main reason for this breakage is that these sites only support
> > Diffie-Hellman with 1024-bit parameters which are considered too
> > weak
> > by this change.
> 
> Setting up a unified distro-wide crypto policy was a Good Thing, but
> we 
> have to use it responsibly. Unfortunately, I don't think it's
> practical 
> for Fedora to increase the minimum required Diffie-Hellman parameter 
> size to 2048 until either Firefox or Chrome has done so first. Users 
> are just going to object that they can't use Fedora to access
> various 
> important websites, and those important websites will never be fixed
> so 
> long as they're only broken for Fedora users. We should consider 
> ourselves at the mercy of the major browser vendors to implement new 
> restrictions before we do. It's a shame that major browsers are so 
> unwilling to break websites, even when it's clearly important for 
> security, but that's the world we live in. :/
> 
> Alternatively, if you want to strengthen the system crypto policy,
> then 
> it should not apply to web browsers at all. Or web browsers should 
> automatically use the weak policy. (We'd need the weak policy in 
> glib-networking, too.)

I agree we need to have the DEFAULT policy be applicable to all
applications, browsers and not (otherwise we end up in reports like
curl and wget don't work while firefox does). It is important though to
gather all data we can from the user reports before reverting, in order
to better understand why that doesn't work, which apps are affected and
better predict when we can make it work.

From the current reports, I believe we have two classes of systems
which cause a problem. (1) systems with implementations which don't
support elliptic curves (that may be rhel5, centos5), and the
administrator set up 1024-bit DH parameters, (2) cisco VPN servers
which are configured to use 1024-bit DH parameters.

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

fedora28 and strong crypto settings

[Nikos Mavrogiannopoulos]

Hi,
 regarding the strong crypto change in Fedora28 [0], we have identified
few (usually internal) sites which break under firefox or other tools.
The main reason for this breakage is that these sites only support
Diffie-Hellman with 1024-bit parameters which are considered too weak
by this change.

I believe however that we should gather as many data as we can related
to this security update in Fedora28, and decide after F28 beta is
released on whether to back this change off, or to ignore this
breakage. Any data gathered is very useful in planning a future
strengthening. Any objections?

For any issues regarding crypto breakage in F28 please use
https://bugzilla.redhat.com/show_bug.cgi?id=1534532
to report it.

regards,
Nikos


[0].
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

gnome-keyring registered tokens in Fedora

[Nikos Mavrogiannopoulos]

Hi,
 I've filled [0] against gnome-keyring, due to it registering PKCS#11
tokens system-wide, which are not generally functional. For example
they are quite limited in the algorithms they support, they pose quite
some obstacles when trying to use them as a generic software smart card
(e.g., like softhsm), and so on. My question is, are there are other
non-generic uses which would make sense for Fedora registering the
gnome-keyring tokens for system-wide use?

regards,
Nikos

[0].
https://bugzilla.redhat.com/show_bug.cgi?id=1520268
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: git package history lost?

[Nikos Mavrogiannopoulos]

On Thu, 2017-11-16 at 09:54 +0100, Pierre-Yves Chibon wrote:
> On Thu, Nov 16, 2017 at 09:14:53AM +0100, Nikos Mavrogiannopoulos
> wrote:
> > Hi,
> >  Has anyone noticed any commits disappearing from packages
> > around/after
> > August 16?
> > 
> > Seeing that build for f27:
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=956210
> > 
> > it contains the message:
> > * Wed Aug 16 2017 Nikos Mavrogiannopoulos <n...@redhat.com> -
> > 20170816-
> > 1.git2618a6c
> >  - Updated to latest upstream - Restarts openssh server on policy
> > update
> 
> Koji tells you the URL which was used to trigger the build:
> Source: git://pkgs.fedoraproject.org/rpms/crypto-
> policies?#e4abbf8b20f065dab68c28c33b7b55b4b297bf76
> cf: https://koji.fedoraproject.org/koji/taskinfo?taskID=21257571
> 
> Which corresponds to this commit in git:
> https://src.fedoraproject.org/rpms/crypto-policies/c/e4abbf8b20f065da
> b68c28c33b7b55b4b297bf76
> 
> That commit is indeed in master but not in f27.

Given that, it seems that there was a desync between the branched git
for f27 and the build for it. Was that just an unlucky build that got
from master to 27, while its corresponding code didn't?

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

git package history lost?

[Nikos Mavrogiannopoulos]

Hi,
 Has anyone noticed any commits disappearing from packages around/after
August 16?

Seeing that build for f27:
https://koji.fedoraproject.org/koji/buildinfo?buildID=956210

it contains the message:
* Wed Aug 16 2017 Nikos Mavrogiannopoulos <n...@redhat.com> - 20170816-
1.git2618a6c
 - Updated to latest upstream - Restarts openssh server on policy
update


However, going to the repo for f27 at:
https://src.fedoraproject.org/rpms/crypto-policies/blob/f27/f/crypto-policies.spec#_102

That message is no longer there.

Commit history has also no mentioning of that date.
https://src.fedoraproject.org/rpms/crypto-policies/commits/f27

It seems that this particular commit has disappeared from git history
in src.fedoraproject.org. Have others noticed something similar, or
could it be that messed something up?

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

orphaned protobuf-c-compiler

[Nikos Mavrogiannopoulos]

Hi,
 I have orphaned this package.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: ansible1.9 package

[Nikos Mavrogiannopoulos]

On Sat, 2017-11-04 at 10:33 -0700, Kevin Fenzi wrote:
> 
> > Breaking updates would be pushed only at these times (unless there
> > is a
> > *really* good reason). This could involve also writing some release
> > notes
> > (e.g. the packager could tick a box "breaking update" and submit a
> > note which
> > is then added to the release notes).
> > 
> > Currently EPEL is basically a "rolling release" distro which is
> > probably the
> > opposite of what RHEL/CentOS users are looking for.
> 
> We have talked about doing this kind of thing in the past, but...
> it's a
> ton more work (you have to have releng folks do a bunch of work every
> 3
> months or whatever) and we could never agree on the timing. Is it
> just
> randomly every 3 months? everytime a new RHEL minor is out? Every
> time a
> new CentOS minor is out?

With the perspective of someone who has seen the described problem
repeatedly as an EPEL contributor, does it really matter which one
option is chosen?

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

Re: story of kerberos

[Nikos Mavrogiannopoulos]

On Fri, 2017-09-08 at 10:39 -0400, Randy Barlow wrote:
> On 09/08/2017 02:40 AM, Nikos Mavrogiannopoulos wrote:
> > > The currently implementation of the Bodhi CLI subclasses
> > > fedora.client.OpenIdBaseClient, which does not support kerberos:
> > > 
> > > https://github.com/fedora-infra/bodhi/blob/2.10.1/bodhi/client/bi
> > > ndin
> > > gs.py#L105
> > 
> > Is there a bug opened on this component for that?
> 
> There does not appear to be:
> 
> https://github.com/fedora-infra/python-fedora/issues
> 
> I believe the intention is to move Fedora apps authentication from
> OpenID to OpenID Connect, but I'll defer to Patrick on that.

Thank you.

I've opened a bug there:
https://github.com/fedora-infra/python-fedora/issues/202

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

Re: story of kerberos

[Nikos Mavrogiannopoulos]

On Thu, 2017-09-07 at 15:25 -0400, Randy Barlow wrote:
> On 09/07/2017 09:14 AM, Nikos Mavrogiannopoulos wrote:
> > It works with the browser indeed. Would it work with command line
> > tools
> > like bodhi as well?
> 
> The currently implementation of the Bodhi CLI subclasses
> fedora.client.OpenIdBaseClient, which does not support kerberos:
> 
> https://github.com/fedora-infra/bodhi/blob/2.10.1/bodhi/client/bindin
> gs.py#L105

Is there a bug opened on this component for that?

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

Re: story of kerberos

[Nikos Mavrogiannopoulos]

On Wed, 2017-09-06 at 09:51 -0700, Kevin Fenzi wrote:
> On 09/06/2017 05:25 AM, Nikos Mavrogiannopoulos wrote:
> > Hi,
> >  What's the story between the recently introduced support of
> > kerberos
> > in koji? My understanding was that eventually all services of
> > fedora
> > would switch to kerberos authentication, though information on the
> > following bugs for bodhi seems to contradict that:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1483538
> > https://github.com/fedora-infra/bodhi/issues/1179
> 
> I'm not sure where you got the understanding that everything was
> moving
> to kerberos. Did we say that somewhere?
> > In fact currently we have:
> >  * To change code: ssh public key authentication
> >  * To compile changed code: koji: kerberos ticket
> >  * To submit a changed package: bodhi: raw passwords
> >  * To subscribe to a mailing list: lists.fedoraproject.org: openid?
> > 
> > and probably few more options that I missed. Is there an
> > integration
> > story behind all these, or is it intentional that various different
> > services will require different credentials?
> 
>  For ssh keys, we are looking at various options. Possibly ssh
> certificates. Patrick has been investigating this.

It would really increase usability to have kerberos auth in SSH. Having
another credential like ssh certificate would mean even more stuff to
take care of as fedora developer.


> For all the web apps we have now (except wiki, but it should move
> soon),
> we should have openid or openid-connect. In that case if you have a
> valid kerberos ticket, your browser is configured right (default in
> all
> recent ones), you automatically can authenticate via ipsilon.
> 
> ie, you click the login thing, it redirects to ipsilon, which sees
> you
> have a valid kerberos ticket and just authenticates you. Do you not
> see this happening there?

It works with the browser indeed. Would it work with command line tools
like bodhi as well?

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

story of kerberos

[Nikos Mavrogiannopoulos]

Hi,
 What's the story between the recently introduced support of kerberos
in koji? My understanding was that eventually all services of fedora
would switch to kerberos authentication, though information on the
following bugs for bodhi seems to contradict that:

https://bugzilla.redhat.com/show_bug.cgi?id=1483538
https://github.com/fedora-infra/bodhi/issues/1179

In fact currently we have:
 * To change code: ssh public key authentication
 * To compile changed code: koji: kerberos ticket
 * To submit a changed package: bodhi: raw passwords
 * To subscribe to a mailing list: lists.fedoraproject.org: openid?

and probably few more options that I missed. Is there an integration
story behind all these, or is it intentional that various different
services will require different credentials?

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

what's the story with kerberos

[Nikos Mavrogiannopoulos]

-- 
Nikos Mavrogiannopoulos, PhD,
Crypto Tech. Lead,
Security Technologies,
Red Hat, Inc.



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

Re: F28 System Wide Change: Switch libidn-using applications to IDNA2008

[Nikos Mavrogiannopoulos]

On Fri, 2017-08-25 at 08:56 -0500, Michael Catanzaro wrote:
> On Fri, Aug 25, 2017 at 1:24 AM, Jan Kurik  wrote:
> > The proposed change is about deprecating libidn, which supports
> > IDNA2003, and switch all applications using libidn, to libidn2
> > 2.0.0,
> > which supports IDNA2008.
> 
> Any plans to migrate applications that use ICU's deprecated IDNA2003 
> functions?

I'm not familiar with ICU so I left it outside the scope of that
change. However, it would make sense to have a larger change that
includes ICU as well.

Currently most challenges were on subtle incompatibilities between
libidn and libidn2.

> Thanks for pointing out that WebKit has (quite recently) switched to 
> nontransitional IDNA2008. Epiphany is still doing transitional 
> processing. I'll turn that off now.

Note that as a browser you may want to be as compatible as possible.
Firefox for example switches to IDNA transitional (i.e., 2003) when the
string cannot be expressed in IDNA2008 (e.g., contains disallowed
characters). With libidn2 that can be expressed as:
https://libidn.gitlab.io/libidn2/manual/libidn2.html#Converting-with-backwards-compatibility

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

Re: F28 System Wide Change: Switch libidn-using applications to IDNA2008

[Nikos Mavrogiannopoulos]

On Fri, 2017-08-25 at 14:38 +0200, Kevin Kofler wrote:
> Jan Kurik wrote:
> > * Other developers:
> > Maintainers, should
> > - Verify that their software is linked with the libidn library
> > - Update the software from upstream if it already has been
> > converted to
> > libidn2
> > - Check the libidn2 instructions on converting a package to
> > libidn2.
> > - Propose patches (trivial task) to convert to libidn2, and
> > notify upstream about it.
> > In short switch software from libidn to libidn2, it is sufficient
> > replacing idna.h header with idn2.h.
> 
> I repeat again what I already wrote when this was initially
> announced, 
> because it was ignored:
> 
> I do not see why we need to patch each and every application for
> this. Since 
> the library is at least API-compatible (not sure about the ABI),
> libidn2-
> devel should have Obsoletes and Provides for libidn-devel and
> symlinks 
> libidn.so → libidn2.so and idn.h → idn2.h. Then all that is needed
> in 
> application packages is a rebuild. Changing one package scales much
> better 
> than changing all other packages.

libidn contains more than IDNA2003 functionality, such as stringprep et
al. Libidn2 contains only IDNA2008 functionality, so there cannot be a
1-1 mapping between the two libraries and libidn2 cannot replace libidn
for the protocols which still rely on stringprep. Stringprep is an
IDNA2003 requirement but some protocols such as XMPP rely on it.

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

Re: F28 System Wide Change: Switch libidn-using applications to IDNA2008

[Nikos Mavrogiannopoulos]

On Fri, 2017-08-25 at 08:38 +0200, Tomasz Torcz wrote:
> On Fri, Aug 25, 2017 at 08:24:30AM +0200, Jan Kurik wrote:
> > = Proposed System Wide Change: Switch libidn-using applications to
> > IDNA2008 =
> > https://fedoraproject.org/wiki/Changes/IDNA2008
> > 
> > Change owner(s):
> > * Nikos Mavrogiannopoulos 
> > * Robert Scheck 
> > 
> > The proposed change is about deprecating libidn, which supports
> > IDNA2003, and switch all applications using libidn, to libidn2
> > 2.0.0,
> > which supports IDNA2008.
> 
>   Are the issues with systemd+libidn2 resolved? This is critical
> chain, after all.

Not sure what you mean, but you can find more information on the
relevant bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1449145

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

Re: IDNA2008 change impact on installation size

[Nikos Mavrogiannopoulos]

On Fri, 2017-05-12 at 16:05 +, Zbigniew Jędrzejewski-Szmek wrote:
> Hi,
> 
> has any consideration been give to the size increase required by the
> change from libidn (678k) to libidn2 + libunistring (228k + 1246k)?
> That's not *too* bad, since currently none of the things which depend
> on idn end up in the initramfs, but still, it's noticeable.

Note also that these packages will increase in size as unicode standard
evolves. libidn due to IDNA2003 was tied to a specific old standard
while libunistring gets updated to the latest one thus includes much
more data than the previous ones.

I do not know whether the glibc switch from libidn to libidn2 would
provide some benefit in that aspect.

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

Switch to IDNA2008 (should we keep libidn?)

[Nikos Mavrogiannopoulos]

On Tue, 2017-04-04 at 08:44 +0200, Jan Kurik wrote:
> = Proposed System Wide Change: Switch libidn-using applications to
> IDNA2008 =
> https://fedoraproject.org/wiki/Changes/IDNA2008
> 
> Change owner(s):
> * Nikos Mavrogiannopoulos 
> * Robert Scheck 
> 
> The proposed change is about deprecating libidn, which supports
> IDNA2003, and switch all applications using libidn, to libidn2 2.0.0,
> which supports IDNA2008.
> 
> 
> == Detailed Description ==
> Internationalized domain names exist for quite some time (IDNA2003),
> although the protocols describing them have evolved in an
> incompatible
> way (IDNA2008). These incompatibilities will prevent applications
> written for IDNA2003 to access certain problematic domain names
> defined with IDNA2008, e.g., faß.de is translated to domain
> xn--fa-hia.de with IDNA2008, while in IDNA2003 it is translated to
> fass.de domain. That not only causes incompatibility problems, but
> may
> be used as an attack vector to redirect users to different web sites.
> 
> The proposed change is about deprecating libidn, which supports
> IDNA2003, and switch all applications using libidn, to libidn2 2.0.0,
> which supports IDNA2008. The switch should be transparent as the
> libidn2 library is API compatible.
> 
> Note that even in the web browsers, field there is much confusion on
> the topic. Chromium appears to use IDNA2008 transitional (i.e.,
> IDNA2003 mapping for the problematic characters), while Firefox and
> Safari have already moved to IDNA2008.
> 
> For more information see:
> * http://nmav.gnutls.org/2017/04/the-mess-with-internationalized-doma
> in.html
> * https://www.plesk.com/blog/what-is-the-problem-with-s/
> * http://unicode.org/faq/idn.html#6
> 
> 
> == Scope ==
> * Proposal owners:
> The proposal owner is expected to co-ordinate and fill the required
> bugs on the distribution.

What was left out of the proposal is whether we should keep libidn in
the OS. IDNA2003 may still be in use somewhere, but even when it is, it
is via IDNA2008-transitional mode. Are there any other reasons to keep
libidn in Fedora?

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

Re: IDNA2008 change impact on installation size

[Nikos Mavrogiannopoulos]

On Mon, 2017-05-15 at 09:42 -0400, Matthew Miller wrote:
> On Fri, May 12, 2017 at 04:05:50PM +, Zbigniew Jędrzejewski-Szmek 
> wrote:
> > has any consideration been give to the size increase required by
> > the
> > change from libidn (678k) to libidn2 + libunistring (228k + 1246k)?
> > That's not *too* bad, since currently none of the things which
> > depend
> > on idn end up in the initramfs, but still, it's noticeable.
> 
> Thanks for considering this angle. Is there a way to reduce that?
> Looks like libunistring is just... large.

We could include a libidn2 which only contains the parts of
libunistring that it needs via gnulib. That could reduce the size
significantly, at the cost of including a library as static.

My understanding of libunistring is that it is going to be widely used
for UTF conversions and internationalized string handling given that
the posix APIs in libc are terrible in that aspect. I believe it is
already widely used mostly as gnulib module (copylib).

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

Re: automated packaging

[Nikos Mavrogiannopoulos]

On Thu, 2017-03-23 at 09:54 -0700, Adam Williamson wrote:
> On Thu, 2017-03-23 at 09:20 +0100, Nikos Mavrogiannopoulos wrote:
> > 
> > > FWIW, I would be *extremely* reluctant to use something that big
> > > that's
> > > a) written in shell script (ugh) and b) has no tests.
> > 
> > How did you figure the (b) part? The package itself has extensive
> > tests.
> 
> I meant that, so far as I can see in
> https://github.com/cockpit-project/cockpituous/ , there are no tests
> for the 'release' scripts. If there are, can you point me to them?

You are right. There are none on the cockpituous package.

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

Re: automated packaging

[Nikos Mavrogiannopoulos]

On Fri, 2017-03-24 at 08:27 +0100, Dan Horák wrote:
> On Fri, 24 Mar 2017 07:10:47 + (UTC)
> Petr Pisar  wrote:
> 
> > On 2017-03-23, Michael Catanzaro  wrote:
> > > On Thu, 2017-03-23 at 06:32 -0500, Michael Catanzaro wrote:
> > > > That's not true, there are ABI checks in the sidebar on koji.
> > > 
> > > Sorry, in the sidebar in *Bodhi*.
> > 
> > Could you be more specific (URL or so)? I cannot find it on Bodhi
> > web
> > site.
> 
> It would be under the "Automated Test Results", but the libabigail
> tests are enabled now only for critical path packages. But it should
> be
> really enabled for all and made to require a manual waiver if an
> incompatible result is detected.

I do not see that in gnutls [0] so it may be selectively enabled even
for critical path packages. I agree that it should be there for all
with a manual waiver.

regards,
Nikos


[0]. https://bodhi.fedoraproject.org/updates/FEDORA-2017-5a55b061cb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: automated packaging

[Nikos Mavrogiannopoulos]

On Thu, 2017-03-23 at 09:35 +0100, Miroslav Suchý wrote:
> Dne 23.3.2017 v 09:23 Nikos Mavrogiannopoulos napsal(a):
> > What I was
> > interested is whether there is plan or intention of improving the
> > fedora infrastructure for packagers by making these part of our
> > daily
> > work-flow.
> 
> It depends. :)
> I use Tito daily and it saves me a lot of time. However some people
> find it too complicate/less powerfull/hard to
> understand/not enough powerfull... so they use some other tool.
> People are different and they like different tools. And I'm afraid
> that fedpkg is biggest common denominator.
> 
> So I would say: go ahead, write blogposts about your tool, continue
> to enhance it or join your effort with some other
> tool from the list Colin compiled. But there is 0% chance that it
> will be wide enforced tool for all Fedora contributors.

Note that this is not my tool, and my post is not about imposing any
specific tool. What I'm trying to suggest here is to move to automated
packaging, not talk about using a tool.

That is, being able to tie certain packages to certain upstream streams
per release using the fedora infrastructure. That is, set package xyz,
tied to upstream 1.2.x branch, and update as needed (maybe with manual
confirmation/review from maintainer, maybe not).

It is the monkey work I would like to eliminate.

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

Re: automated packaging

[Nikos Mavrogiannopoulos]

On Wed, 2017-03-22 at 11:36 +0100, Miroslav Suchý wrote:
> Dne 22.3.2017 v 11:00 Nikos Mavrogiannopoulos napsal(a):
> > Hi,
> >  For several packages it is possible to automate build, test and
> > package updating on multiple fedora releases (+epel) in a single
> > keypress using the cockpituous (sic) tools [0]. These tools hide
> > quirks
> > and requirements of the fedora tooling, and allow a very efficient
> > orchestration of package releases (see [1] for a script which
> > releases
> > gnutls  for example).
> 
> 
> Few comments from my quick review:
> + it can release to Debian and Docker
> - user have to put quite a lot of logic and repetitive configuration
> in `make-release` (for every project)
> - not really well documented
> 
> There already exist much olders and IMO betters tools which can
> release from upstream directly to Fedora:
>   https://github.com/dgoodwin/tito/
>   https://github.com/openstack-packages/rdopkg
>   https://github.com/ignatenkobrain/rpm-gitoverlay

The look fine too. I am not tied to a particular tool. What I was
interested is whether there is plan or intention of improving the
fedora infrastructure for packagers by making these part of our daily
work-flow.

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

Re: automated packaging

[Nikos Mavrogiannopoulos]

On Wed, 2017-03-22 at 08:51 -0700, Adam Williamson wrote:
> On Wed, 2017-03-22 at 11:00 +0100, Nikos Mavrogiannopoulos wrote:
> > Hi,
> >  For several packages it is possible to automate build, test and
> > package updating on multiple fedora releases (+epel) in a single
> > keypress using the cockpituous (sic) tools [0]. These tools hide
> > quirks
> > and requirements of the fedora tooling, and allow a very efficient
> > orchestration of package releases (see [1] for a script which
> > releases
> > gnutls  for example).
> > 
> > I'm transforming more of the packages I maintain to that form,
> > however,
> > there is much more value if that is done once for all the Fedora
> > maintainers. While obviously the maintainers who are also involved
> > in
> > upstream developing would benefit most, the majority of the
> > maintainers
> > which have packages which follow good practices will benefit from
> > such
> > a simple automated rebase, spending their time only for reviewing
> > changes. Is that something that is already being worked on?
> 
> FWIW, I would be *extremely* reluctant to use something that big
> that's
> a) written in shell script (ugh) and b) has no tests.

How did you figure the (b) part? The package itself has extensive
tests.

Unless you mean about fedora testing in general. It is true fedora
provides no practical infrastructure for testing. Even basic checks
like ABI checks for libraries are missing on updates; that's sad but
shouldn't stop packagers from improving their life.

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

automated packaging

[Nikos Mavrogiannopoulos]

Hi,
 For several packages it is possible to automate build, test and
package updating on multiple fedora releases (+epel) in a single
keypress using the cockpituous (sic) tools [0]. These tools hide quirks
and requirements of the fedora tooling, and allow a very efficient
orchestration of package releases (see [1] for a script which releases
gnutls  for example).

I'm transforming more of the packages I maintain to that form, however,
there is much more value if that is done once for all the Fedora
maintainers. While obviously the maintainers who are also involved in
upstream developing would benefit most, the majority of the maintainers
which have packages which follow good practices will benefit from such
a simple automated rebase, spending their time only for reviewing
changes. Is that something that is already being worked on?

regards,
Nikos


[0]. https://github.com/cockpit-project/cockpituous/
[1]. https://github.com/nmav/fedora-gnutls
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

orphaning: sniproxy

[Nikos Mavrogiannopoulos]

Hello,
 I'm orphaning the sniproxy package because I no longer use it and
haproxy seems to be quite superior in features/performance. If you are
interested please consider adopting it.

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

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

[EPEL-devel] rethinking the epel testing

[Nikos Mavrogiannopoulos]

Hi,
 As it is now in the EPEL package update process the testing phase
takes 14 days (double of Fedora). My impression is that this testing
phase is quite long and unhelpful for the following reasons:

1. The majority of people who use EPEL are not Fedora users. They are
more likely to report a bug they encounter, in CentOS forums (or RHEL)
rather than understand fedora process and the need for karma.

2. The testing-imposed delay does not help detecting failures such as a
library ABI breakage as in:
https://bugzilla.redhat.com/show_bug.cgi?id=1411021
My guess is that these systems upgrade on even slower cycle than 14
days (it may even be the RHEL/Centos cycles).


Most likely only then an issue will be spotted and the 14-day delay
prevents from providing fast a fix. 

I do not have any good suggestion, other than reducing the long period
of testing to the Fedora defaults (7 days). A better approach would be
to tie more to centos processes, and allow centos registered users to
give karma and test, but I have no idea how feasible it is, and whether
centos users will actually get involved in EPEL.

regards,
Nikos

[0]. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-63c298b073
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

f25 buildroot seems to be broken

[Nikos Mavrogiannopoulos]

Any fedpkg scratch-builds or builds fail. root.log contains:

DEBUG util.py:435:  Last metadata expiration check: 0:00:16 ago on Tue
Jan 17 08:06:22 2017.
DEBUG util.py:435:  Error: nothing provides publicsuffix-list-dafsa
needed by libpsl-0.17.0-1.fc25.x86_64.
DEBUG util.py:435:  nothing provides publicsuffix-list-dafsa needed by
libpsl-0.17.0-1.fc25.x86_64
DEBUG util.py:435:  (try to add '--allowerasing' to command line to
replace conflicting packages)


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

Re: F26 System Wide Change: Switch OpenLDAP from NSS to OpenSSL

[Nikos Mavrogiannopoulos]

On Thu, 2017-01-05 at 16:02 +0100, Tomasz Torcz wrote:
> On Thu, Jan 05, 2017 at 03:55:41PM +0100, Jan Kurik wrote:
> > = System Wide Change: Switch OpenLDAP from NSS to OpenSSL =
> > https://fedoraproject.org/wiki/Changes/OpenLDAPwithOpenSSL
> > 
> > Change owner(s):
> > * Matus Honek 
> > 
> > Currently, OpenLDAP in Fedora is compiled with NSS (aka MozNSS) for
> > cypto. OpenLDAP is going to be compiled with OpenSSL, instead.
> 
> 
>   Are you
> undoing  https://fedoraproject.org/wiki/FedoraCryptoConsolidation ?

Please check the Note on top of this page. This is no longer on-going
effort. We encourage packagers to use the libraries recommended by
upstream, and _NOT_ what is suggested by this old page.

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

ssh using kerberos (was: Packagers - Flag day 2016 Important changes)

[Nikos Mavrogiannopoulos]

On Sun, 2016-12-11 at 18:34 -0600, Dennis Gilmore wrote:
> Greetings. 
> 
> As previously announced, releng has made a number of changes as part
> of
> it's 2016 "flag day". 
> 
> All package maintainers will want to make sure they have updated to
> the 
> following package versions (some may be in testing as of this email):
> 
>  python-cccolutils-1.4-1
>  fedpkg-1.26-2
>  fedora-packager-0.6.0.0-1
>  pyrpkg-1.47-3
>  koji-1.11.0-1
> 
> Please also see the following links for up to date information: 
> 
> https://fedoraproject.org/wiki/ReleaseEngineering/FlagDay2016
> 
> The following changes were made:
> 
> * koji and the source lookaside were changed to use kerberos
> authentication
> instead of ssl certificates. All maintainers will need to:
> 
> kinit your-fas-accountn...@fedoraaproject.org
> 
> to get a valid kerberos TGT and be able to authenticate to koji and 
> the lookaside upload cgi. 

Will this include a switch to GSSAPI for SSH? As it is now the SSH
private key is still needed to commit to git repositories, even if a
valid ticket is present.

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

Re: crypto-policies not very useful, FUTURE too strict?

[Nikos Mavrogiannopoulos]

On Mon, 2016-12-19 at 11:07 +0100, Tomasz Torcz wrote:
> On Mon, Dec 19, 2016 at 09:35:09AM +0100, Nikos Mavrogiannopoulos
> wrote:
> > On Sat, 2016-12-17 at 16:19 +0100, Tomasz Torcz wrote:
> > > Hi,
> > > 
> > >   Since few release we have nifty, consolidated way to select
> > > system-
> > > wide crypto
> > > policy. It's great, but granularity of selection is little
> > > lacking. 
> > > We have
> > > basically two sensible choices:
> > > - DEFAULT, which is, well, default
> > 
> > That is one of the main goals of crypto policies. To set a sensible
> > default across the system applications, irrespective of which back-
> > end
> > library it uses. It should not be underestimated, as even now we
> > are
> > not there yet, especially with the applications depending on the
> > less
> > known tls libraries, or applications using libssh*.
> > 
> > As a general goal, the intention of the FUTURE policy is not to be
> > compatible with the rest of the internet. That's the goal of the
> > DEFAULT policy. The FUTURE is intended to be compatible with
> > servers
> > using parameters which are considered secure.
>   So, what exactly is the use case behind this preference?

Administrators which need to set their system on a specific security
level. Future is defined to be on the 112-bit level.

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

Re: crypto-policies not very useful, FUTURE too strict?

[Nikos Mavrogiannopoulos]

On Mon, 2016-12-19 at 09:35 +0100, Nikos Mavrogiannopoulos wrote:

$ update-crypto-policies --set FUTURE
Setting system policy to FUTURE

$ wget https://github.com
Resolving github.com (github.com)... 192.30.253.112, 
192.30.253.113  
 github.com
(github.com)|192.30.253.112|:443... connected
ERROR: The certificate of 'github.com' is not trusted.
ERROR: The certificate of 'github.com' was signed using an insecure
algorithm.

The example you have above is a glitch on the combination of the
shared
system store use and crypto policies at gnutls.

Actually it relates to a particular behavior of wget [0]. In fact it
was disabling the system-wide policy as soon as it was enabling it.

[0]. https://bugzilla.redhat.com/show_bug.cgi?id=1405956

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

Re: crypto-policies not very useful, FUTURE too strict?

[Nikos Mavrogiannopoulos]

On Sat, 2016-12-17 at 16:19 +0100, Tomasz Torcz wrote:
> Hi,
> 
>   Since few release we have nifty, consolidated way to select system-
> wide crypto
> policy. It's great, but granularity of selection is little lacking. 
> We have
> basically two sensible choices:
> - DEFAULT, which is, well, default

That is one of the main goals of crypto policies. To set a sensible
default across the system applications, irrespective of which back-end
library it uses. It should not be underestimated, as even now we are
not there yet, especially with the applications depending on the less
known tls libraries, or applications using libssh*.

> - FUTURE, which is said to be more secure; if the admin wants to
> change the policy,
>   (s)he will have to switch to FUTURE
>  So let's imagine Joe Sysadmins who in the face of LogJam and other
> vulnerabilites,
> wants to tighten security a bit. He switches to FUTURE and now GitHub
> doesn't work:

As a general goal, the intention of the FUTURE policy is not to be
compatible with the rest of the internet. That's the goal of the
DEFAULT policy. The FUTURE is intended to be compatible with servers
using parameters which are considered secure.

> $ update-crypto-policies --set FUTURE
> Setting system policy to FUTURE
> 
> $ wget https://github.com
> Resolving github.com (github.com)... 192.30.253.112, 
> 192.30.253.113  
>  github.com
> (github.com)|192.30.253.112|:443... connected
> ERROR: The certificate of 'github.com' is not trusted.
> ERROR: The certificate of 'github.com' was signed using an insecure
> algorithm.

The example you have above is a glitch on the combination of the shared
system store use and crypto policies at gnutls. Please file a bug on
it. That host should have been within the crypto policies FUTURE
requirements.

>  Should we introduce another level, like FUTURE-BUT-WORKING?  With
> secure settings,

No. The purpose of the policies is to provide levels of assurance. A
connection is within that set or not. FUTURE-BUT-WORKING doesn't mean
anything; the DEFAULT policy serves that purpose.

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

Re: rawhide: Illegal char '-' (0x2d) in: Release: 3.fc26-pending

[Nikos Mavrogiannopoulos]

On Wed, 2016-12-14 at 12:12 +0100, Igor Gnatenko wrote:
> On Wed, Dec 14, 2016 at 12:00 PM, Nikos Mavrogiannopoulos
> <n...@redhat.com> wrote:
> > Any idea on why this happens when attempting to build in rawhide?
> > Is
> > the buildroot broken?
> 
> You need to update fedpkg/pyrpkg.

The version from updates-testing solves the issue, thanks.

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

rawhide: Illegal char '-' (0x2d) in: Release: 3.fc26-pending

[Nikos Mavrogiannopoulos]

Any idea on why this happens when attempting to build in rawhide? Is
the buildroot broken?

$ fedpkg build
error: line 6: Illegal char '-' (0x2d) in: Release: 3.fc26-pending
error: query of specfile /home/.../fedora/gnutls/gnutls.spec failed,
can't parse

The line in question has:
Release: 3%{?dist}


Builds in other branches work fine.

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

Re: a diversion into EPEL [was Re: Two more concrete ideas for what a once-yearly+update schedule would look like]

[Nikos Mavrogiannopoulos]

On Fri, 2016-12-09 at 11:17 -0500, Matthew Miller wrote:
> On Fri, Dec 09, 2016 at 11:07:32AM -0500, Colin Walters wrote:
> > > Anyways, in the big picture, while I don't speak for everyone on
> > > the Project Atomic side, I personally point users at CentOS
> > > first,
> > > unless I have some reason to think they want Fedora. Something
> > > like
> > > 80% of Fedora usage hitting the mirrors was desktop systems,
> > > right?
> > > I don't expect that to change personally.
> > 
> > Although..except for EPEL.  And how EPEL works should obviously be
> > part of this. Things would feel clearer if EPEL lived in CentOS now
> > perhaps.
> Right; in mirror traffic, EPEL is to Fedora Workstation as
> Workstation
> is to Server. :)
> 
> EPEL packages *are* Fedora packages, though — moving the project to
> CentOS isn't completely crazy, but would require a lot more
> integration and cooperation between the projects.

Right, it would have to be easy for maintainers to contribute in both.

> That's something I'd like to see anyway. I think there are a lot of
> opportunities for this with containers and modularity — if you can
> just run Fedora containers on CentOS or RHEL *directly*, why bother
> rebuilding them? 

I agree that can be an option in some cases, however, I can think of a
few cases which it cannot. (a) running centos7 on a container, without
epel you cannot have that additional software, (b) kernel features
which are available in Fedora but not in centos7, may cause the
software not to work if they don't detect the features on runtime, (c)
simplicity; not having to go through the path of having to run special
tools for scanning vulnerabilities in running containers.

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

Re: yubico-piv-tool & p11-kit

[Nikos Mavrogiannopoulos]

On Tue, 2016-12-06 at 13:44 +0100, Jakub Jelen wrote:

> > > > They don't, in fact, have different URIs. If I add a .module
> > > > file for
> > > > ykcs11.so, I get the attached output for p11tool --list-tokens.
> > > 
> > > You forgot to attach it :)
> > 
> > Let's try again. :)
> 
> I suspect the problem is related to the issue #98 on github [1]
> already 
> fixed in git, but not yet released. The PKCS#11 module returns a
> very 
> weird results at this point:
> 
> 239: C_GetSlotList
> 2016-12-06 13:15:19.158
> [in] tokenPresent = 0x1
> [out] pSlotList:
> Slot 0
> Slot -1
> [...garbage values ...]
> [out] *pulCount = 0x30
> Returned:  0 CKR_OK
> 
> I would pull the module to p11-kit no earlier than this will get
> fixed.
> 
> Also the duplicate keys might be related to the issue #101 [2]. The 
> returned values might be really different objects, bug Yubico is
> unable 
> to get the serial from them. This module might be good enough for 
> yubico-piv-tool, but I am not sure if for other use cases (p11-kit
> and system-wide querying).

It makes sense not to register incomplete or modules applicable to a
single application (internal) system-wide. I've updated the proposed
guidelines to say: "Any package in Fedora containing a PKCS#11 provider
module, intended to be used outside this package, must be registered
with p11-kit. " [0].

regards,
Nikos

[0]. https://fedoraproject.org/wiki/PackagingDrafts/Pkcs11Support

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

Re: yubico-piv-tool & p11-kit

[Nikos Mavrogiannopoulos]

On Mon, 2016-12-05 at 10:23 -0500, Nathaniel McCallum wrote:

> > Indeed, in the case where one has both ykcs11 and opensc, he would
> > have
> > to supply --detailed-urls to p11tool to be able to distinguish
> > between
> > objects. That is, because they will have identical URLs except for
> > the
> > library-description and library-manufacturer fields, which are not
> > normally printed.
> > 
> > That would be a bit more than just inconvenience because of the
> > duplicate listings, it would be that if you don't specify the
> > library
> > fields on the URL, you wouldn't know which module was used for the
> > operation.
> 
> They don't, in fact, have different URIs. If I add a .module file for
> ykcs11.so, I get the attached output for p11tool --list-tokens.

You forgot to attach it :)

> > We should ping yubico on that. Is there some reason they didn't
> > implement the key generation on opensc? Ideally we won't ship that
> > additional module.
> 
> I don't know. But I suspect it would require hardware change. There
> are a lot of existing YubiKeys out there. 

opensc-pkcs11 is an alternative driver for the same hardware, the same
as ykcs11. As it is now, it seems that opensc misses only the
generation part, and I think it would be preferable to pointing yubico
in adding that functionality in opensc, rather than shipping a separate
driver in fedora.

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

[EPEL-devel] specifying a different buildroot

[Nikos Mavrogiannopoulos]

Hi,
 In #1400693 it was reported that a build of a package in epel didn't
work on latest centos7. My understanding is that the latest epel
buildroot is rhel7.3 while centos is compatible with 7.2. Is there some
way to set a specific compilation root for a package? If not could
there be some sync between epel buildroots and released centos?

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

Re: yubico-piv-tool & p11-kit

[Nikos Mavrogiannopoulos]

On Mon, 2016-12-05 at 08:41 +0100, Jakub Jelen wrote:
> On 12/03/2016 01:50 PM, Nathaniel McCallum wrote:
> > So apparently yubico-piv-tool ships $libdir/libykpkcs11.so*, but
> > this
> > doesn't get picked up by p11-kit by default. I suspect it has gone
> > unnoticed largely because for most crucial operations the opensc
> > module also works with Yubikeys. However, this is not true for all
> > operations (in particular, in my case, key creation).
> > 
> > How can we make this happen? Is there some intentional reason
> > Yubico's
> > PKCS#11 module has been excluded?
> Hello,
> In case of the modules accessing the same hardware tokens, there is
> a problem that they shows up more times while listed by p11-kit. We
> had similar problem with opensc && coolkey once both of them worked
> with PIV cards.

Indeed, in the case where one has both ykcs11 and opensc, he would have
to supply --detailed-urls to p11tool to be able to distinguish between
objects. That is, because they will have identical URLs except for the
library-description and library-manufacturer fields, which are not
normally printed.

That would be a bit more than just inconvenience because of the
duplicate listings, it would be that if you don't specify the library
fields on the URL, you wouldn't know which module was used for the
operation.

On the other hand, if we have another pkcs11 module for yubikeys
shipped on a package, it seems natural to be included in the p11-kit
listings, and maybe it makes sense to make p11tool print the long URL
versions by default.

> Ideal solution would be to implement the PIV key creation in OpenSC 
> (what exactly does not work with which yubikey?). We can't use only 
> yubico module, since PIV is not only the yubico one.

We should ping yubico on that. Is there some reason they didn't
implement the key generation on opensc? Ideally we won't ship that
additional module.

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

Re: F26 Self Contained Change: Java/OpenJDK enforces the system-wide crypto policy

[Nikos Mavrogiannopoulos]

On Mon, 2016-11-21 at 12:07 -0600, Michael Catanzaro wrote:
> On Mon, 2016-11-21 at 18:13 +0100, Jan Kurik wrote:
> > 
> > As it is now, the System-wide crypto policy in F25 is enforced by
> > the
> > OpenSSL, GnuTLS and NSS TLS libraries. To harmonize crypto across
> > all
> > applications in Fedora, including the Java ones, OpenJDK is
> > enhanced
> > to respect the settings of the system-wide crypto policy as well.
> 
> This is no longer true. I just got a questionable F24 stable release
> update that implemented this change, so I presume F25 will have it
> soon
> enough. We probably don't want an F26 change proposal for a feature
> that's implemented in a zero-day F25 update.

That wasn't the plan, but it could have been a mistake. Could you add
more info at:
https://bugzilla.redhat.com/show_bug.cgi?id=1249083

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

compat-openssl10-engine_pkcs11

[Nikos Mavrogiannopoulos]

Hi,
 In F26 with the openssl 1.1.0 rebase libp11/engine_pkcs11 will be
compiled only for openssl 1.1.0. That means that there will be no
engine_pkcs11 for the packages linking to openssl 1.0.x. For that I've
created the compat-openssl10-libp11 package which is intended to
provide just that (engine_pkcs11). It will not provide libp11-devel for
these packages, and the shipped libp11 will have different versioned
symbols and soname.

Any objections or issues found with this approach? Otherwise who would
like to review this compat package?

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

regards,
Nikos
___
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

[Nikos Mavrogiannopoulos]

On Tue, 2016-10-11 at 16:46 +, Petr Pisar wrote:
> On 2016-10-11, Remi Collet  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?

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

Re: [SO-NAME BUMP] jsoncpp 1.7.7 comes to rawhide (and maybe to fc25)

[Nikos Mavrogiannopoulos]

On Mon, 2016-10-03 at 06:10 +0200, Björn Esser wrote:
> Chain-build is running: 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=15917326

However it doesn't seem to work:
Error: nothing provides libjsoncpp.so.1()(64bit) needed by cmake-3.6.2-
4.fc26.x86_64


Also fc25 buildroot is broken for cmake pages:
Error: nothing provides libjsoncpp.so.1()(64bit) needed by cmake-3.6.2-
2.fc25.x86_64


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

Re: F26 System Wide Change: OpenSSL 1.1.0

[Nikos Mavrogiannopoulos]

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

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

regards,
Nikos

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

duplicate package on fresh install

[Nikos Mavrogiannopoulos]

Hello,
 A user posted some issue on gnutls [0], and it turned out that after a
fresh install of f24 that user had two versions of the library
installed. I have no idea why this can be or whether that should be
expected from the installer/updater. Any insights?

regards,
Nikos

[0]. https://bugzilla.redhat.com/show_bug.cgi?id=1378781
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[Nikos Mavrogiannopoulos]

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

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

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

[EPEL-devel] conflicting with a devel package

[Nikos Mavrogiannopoulos]

Hi,
 I'm reviewing package [0] for inclusion into epel6 but it provides a
devel package which conflicts with an other devel package from rhel. In
https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies it says "EPEL
packages must never conflict with packages in RHEL Base", however, I'm
not sure whether that includes the -devel packages or not. Could
someone clarify that issue?

regards,
Nikos

[0]. https://bugzilla.redhat.com/show_bug.cgi?id=1366687
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

updating the fedora defensive guide

[Nikos Mavrogiannopoulos]

Hi,
 I've realized that the Fedora defensive guide [0] is the only guide we
have to introduce the C TLS and crypto libraries we have, as well as
provide a defensive style in using them. However, it is quite out-
dated, and misses information which may be standard requirement in the
future (e.g., support for HSMs). For that, I've taken the liberty to
update the text on crypto libraries, as well as the TLS libraries,
i.e., gnutls, Bob Relyea reviewed text on NSS, and we added a section
on using Hardware Security Modules with openssl, gnutls and NSS.

The existing updates are in:
https://pagure.io/defensive-coding-guide/pu
ll-requests

However, what is missing now, is updating the code samples for openssl with 
code that is safe to use with both 1.1.0 and 1.0.0, review the section on 
HSMs+openssl, and add a section on setting up a server with openssl. Anyone who 
knows openssl well enough to volunteer for any of the tasks above?

regards,
Nikos

[0]. 
https://docs.fedoraproject.org/en-US/Fedora_Security_Team/1/html/Defensive_Coding/index.html
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

heads up: engine_pkcs11 merged with libp11

[Nikos Mavrogiannopoulos]

Hi,
 The upstream projects libp11 and engine_pkcs11 have been merged under
the libp11 umbrella. As such, I plan to retire engine_pkcs11, and merge
it with libp11. The only drawback that I see from that move, is that
one would not find the engine_pkcs11 package at the packagedb search
https://admin.fedoraproject.org/pkgdb/


regards,
Nikos
--
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

[Nikos Mavrogiannopoulos]

On Fri, 2016-07-22 at 19:11 +0200, Michael Stahl wrote:
> On 22.07.2016 16:53, Simo Sorce wrote:
> > 
> > On Fri, 2016-07-22 at 16:48 +0200, Tomas Mraz wrote:
> > > 
> > > 
> > > 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.
> > > 
> > I am concerned about a compat package because there are a lot of
> > components lining to openssl often libraries or modules, from
> > different
> > source RPMS. So we incur the risk of getting a binary to link with
> > both
> > version via modules/library dependencies and that would cause
> > issues
> > (probably crashes, or perhaps bad behavior) only at runtime due to
> > symbol aliasing between the two versions.
> 
> urgh, yes, that's practically guaranteed to crash LibreOffice which
> could pull in openssl via neon, python-stmp, postgresql-libs,
> openldap,
> curl, librdf, any gnome-vfs backend, and probably other ways i'm not
> aware of.

As long as the symbols of both libraries are versioned, that should
cause no problem (in theory).

regards,
Nikos
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

notion of base or minimal image

[Nikos Mavrogiannopoulos]

Hi,
 Is there some notion or definition of a Fedora minimal or base image?
I couldn't find some documentation on that. I would like to modify some
script which a package on the critical path depends on, from bash to
perl and I would like to understand whether that could affect any
fedora images.

regards,
Nikos
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: A new way of writing secure code

[Nikos Mavrogiannopoulos]

On Mon, 2016-07-04 at 05:40 +, Ralf Senderek wrote:
> Dear developers, 
> 
> for all who wish to add reliable encryption and authentication
> services to their projects with ease, I'd like to draw your
> attention to cryptlib, which is available in F23, F24, rawhide
> and EPEL 7 stable repositories now. Cryptlib is not just another
> function collection, but offers a High-level interface that makes
> it very easy for inexperienced crypto programmers to write 
> secure code.

But it would be code that will not comply with Fedora's crypto policies
[0]. Until that happens, software using it will have inconsistent
crypto settings and thus I would not recommend using that lib in
Fedora.

regards,
Nikos

[0]. https://fedoraproject.org/wiki/Packaging:CryptoPolicies
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Nikos Mavrogiannopoulos]

On Wed, 2016-06-15 at 12:41 -0400, Russell Doty wrote:


> > Running tracer for a while can really open your eyes to how many
> > things
> > need restarting after normal updates flow. 
> > 
> > One thing that might make this less annoying to people would be
> > ability
> > to schedule the reboot for some off hours time (2am or something)
> > and
> > also ability (for gnome at least) to restore apps/windows/session
> > again on login. 
> > 
> Note that the original poster says that he runs dnf -update from the
> command line because it allows him to do what he wants.
> 
> Based on the information discussed in this thread, shouldn't dnf also
> force a reboot before updates?

I believe you are mixing one technical solution to the upgrading
services problem with user use cases.

Yes, one technical solution to the problem of updating packages is
rebooting before updating. However, as the first poster explained this
is NOT what users do or want to do.

So why not just listen and watch what users do and figure a technical
solution that takes into account their use cases?

regards,
Nikos
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Nikos Mavrogiannopoulos]

On Wed, 2016-06-15 at 10:14 +0200, Ade wrote:
> Hi all
> 
> I dont really want this to be a negative post, just want to share
> something in order to start a healthy discussion
> 
> Background
> Im a Fedora desktop user, have been for many years, going all the way
> back to Fedora Core 1 - I use Fedora on a daily basis, its my main
> (in fact only OS)
> 
> Issue
> Im very comfortable with the CLI, but spend the majority of the time
> in the GUI - I noticed a behaviour change in myself recently - I now
> NEVER use the GUI Software Update tool. I noticed the other day but
> its been like this for quite some time. 
> 
> My workflow is - the GUI tool tells me there are updates, I dismiss
> it and open a terminal and do sudo dnf update -y    
> 
> Why is this?  Well some time ago the behaviour of the tool changed
> and now the only way to proceed is to click in "Restart and Install"
> and this is NEVER what I want to do. I never want to reboot my
> desktop just to apply updates, Id rather apply all the updates and
> reboot to bring in the new kernel (if there is one) when I have the
> time
> I cant help but feel this is, to me anyway,. a broken design, are
> there others that feel the same or am I alone on this

+1

I was always wondering which user scenario the restart and install
covers. On several occasions I could afford an "install + shutdown"
(i.e., when I'm leaving the PC), but restart and install is something
I've never needed/used.

regards,
Nikos
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 Self Contained Change: NSS enforces the system-wide crypto policy

[Nikos Mavrogiannopoulos]

The impact in what sense? Note that openjdk will also conform to the
system wide policy.

regards,
Nikos

On Fri, 2016-05-20 at 15:24 +, Christopher wrote:
> What is the impact on openjdk crypto providers?
> 
> On Fri, May 20, 2016, 05:49 Jan Kurik <jku...@redhat.com> wrote:
> > = Proposed Self Contained Change: NSS enforces the system-wide
> > crypto policy =
> > https://fedoraproject.org/wiki/Changes/NSSCryptoPolicies
> > 
> > Change owner(s):
> > * Nikos Mavrogiannopoulos 
> > 
> > As it is now, the System-wide crypto policy in F24 is only enforced
> > by
> > the OpenSSL and GnuTLS TLS libraries. To harmonize crypto in
> > Fedora,
> > NSS is enhanced to respect the settings of the system-wide crypto
> > policy as well.
> > 
> > == Detailed Description ==
> > As it is now, the System-wide crypto policy in F24 is only enforced
> > by
> > the OpenSSL and GnuTLS TLS libraries. To harmonize crypto in
> > Fedora,
> > NSS is enhanced to respect the settings of the system-wide crypto
> > policy as well.
> > After that change the administrator should be assured that any
> > application that uses NSS will follow a policy that adheres to the
> > configured profile.
> > 
> > 
> > == Scope ==
> > * Proposal owners:
> > The change requires modifying the NSS library to read a policy
> > generated by the crypto-policy package.
> > 
> > * Other developers:
> > There are no required actions by other developers. The change
> > requires
> > only targeted changes to NSS.
> > 
> > * Release engineering:
> > No actions required.
> > 
> > * Policies and guidelines:
> > - The packaging guidelines for crypto policies need to be modified
> > to
> > include NSS in the list of libraries supporting the policies.
> > - The text "(note that adherence to the system-wide policies is
> > work
> > in progress for NSS libraries)" must be removed
> > - The text "Currently the policies are restricted to applications
> > using GnuTLS and OpenSSL" must be changed to include NSS.
> > 
> > * Trademark approval:
> > N/A (not needed for this Change)
> > --
> > Jan Kuřík
> > Platform & Fedora Program Manager
> > Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
> > --
> > devel mailing list
> > devel@lists.fedoraproject.org
> > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraprojec
> > t.org
> > 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.
> org
-- 
Nikos Mavrogiannopoulos, PhD,
Crypto Tech. Lead,
Security Technologies,
Red Hat, Inc.





--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 Self Contained Change: NSS enforces the system-wide crypto policy

[Nikos Mavrogiannopoulos]

On Fri, 2016-05-20 at 10:01 -0500, Michael Catanzaro wrote:
> On Fri, 2016-05-20 at 11:48 +0200, Jan Kurik wrote:
> > 
> > As it is now, the System-wide crypto policy in F24 is only enforced
> > by
> > the OpenSSL and GnuTLS TLS libraries.
> Keep in mind that the system policy is still overridden by glib-
> networking for all GNOME applications.

This is a serious bug, but I don't really want to keep that in mind :) 

I've already commented in
https://bugzilla.redhat.com/show_bug.cgi?id=1179295

regards,
Nikos
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

rawhide build failed

[Nikos Mavrogiannopoulos]

I attempted a build at rawhide [0] but it fails with:
Error: package gettext-devel-0.19.7-4.fc24.x86_64 requires git, but
none of the providers can be installed
(try to add '--allowerasing' to command line to replace conflicting
packages)

Is that an issue at gettext-devel or rawhide building is not broken at
the moment?

regards,
Nikos

[0]. 
https://kojipkgs.fedoraproject.org//work/tasks/6309/14186309/mock_output.log
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

orphaning freeradius-client

[Nikos Mavrogiannopoulos]

Hi,
 I'm orphaning freeradius-client in rawhide and epel. This is a radius
client library. I orphan it because it is not fun working with upstream
and I switched to radcli for my projects.

regards,
Nikos
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Support for PCLMUL, AVX, FMA, etc.

[Nikos Mavrogiannopoulos]

On Fri, 2016-04-01 at 14:32 -0600, Jerry James wrote:
> I am one of the maintainers of the ntl package, which is used by some
> numeric applications (e.g., Macaulay2 and sagemath).  Upstream
> supports use of the PCLMUL instruction, the AVX instructions, and the
> FMA instructions to speed up various computations.  We can't use any
> of those in Fedora, since we have to support a baseline x86_64.
> 
> Well, that's kind of a downer.  I could advertise that people with
> newer CPUs ought to rebuild the ntl package for their own CPUs, but
> what's a distribution for if people have to rebuild packages?  I've
> been looking for a way to automatically support more recent CPUs.
> 
> 
[...]
> Has anybody already thought this through?  What's the best approach
> to
> take?  For this package, the speedups are substantial, so this is
> worth doing, if it can be done well.

In crypto libraries and gmp these optimizations are enabled using
the cpuid information on runtime. That is, check the cpu capabilities
on application/library load and override functions for specific
functionality (e.g., with function pointers) on runtime. Is that
something that can be used by ntl upstream?

regards,
Nikos
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Testing chrony seccomp support

[Nikos Mavrogiannopoulos]

On Mon, 2016-01-18 at 12:51 +0100, Florian Weimer wrote:
> On 01/18/2016 11:02 AM, Nikos Mavrogiannopoulos wrote:
> 
> > As Florian suggested it makes more sense to compartmentalize chrony
> > so
> > that only a small controlled part of it needs to run with seccomp.
> > My
> > recommendation, if you want to use libraries in the filtered code,
> > make
> > their authors aware of that, so that they document any changes in
> > the
> > used system calls, and if possible ask them to document the
> > existing
> > system calls used (e.g., similarly to:
> > http://www.gnutls.org/manual/html_node/Running-in-a-sandbox.html )
> 
> Interesting.  There is one huge caveat:
> 
> > As well as an calls needed for memory allocation to work.
> 
> glibc malloc can basically call *anything*.  We don't know what the
> future will bring.  Currently, we use (off the top of my head, I
> haven't
> checked):

> I appreciate what you are trying to do, but those seccomp filters
> totally break encapsulation.  I have no idea how to support this
> properly, in a sustainable way.  It appears very difficult to do this
> for independently evolving libraries

Well, ignoring the best sandboxing mechanism the linux kernel offers is not 
really a way forward. What would be the alternative? Would something like 
pledge [0,1] be more suitable more suitable to address your concerns?

regards,
Nikos

[0]. http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/pledge
.2?query=pledge
[1]. https://outflux.net/blog/archives/2015/11/11/evolution-of-seccomp/

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Testing chrony seccomp support

[Nikos Mavrogiannopoulos]

On Wed, 2016-01-20 at 14:09 +0100, Florian Weimer wrote:
> On 01/20/2016 01:12 PM, Nikos Mavrogiannopoulos wrote:
> 
> > If you have complex structures to be transfered you may want to
> > rely on
> > something automated to serialize/deserialize requests. That will
> > increase the code, but reduce the complexity. I've used protocol
> > buffers over unix sockets for that exact reason and I'm pretty
> > happy
> > with it.
> 
> I wouldn't use protocol buffers across a security boundaries.  The
> serializers and serializers have integer overflows, and Google
> doesn't
> want to fix them because their use case apparently provides implicit
> message size constraints which make it impossible to trigger these
> issues.
>   https://github.com/google/protobuf/issues/760
>   https://github.com/google/protobuf/issues/761

In my case they don't have an effect either as the maximum message I
can transfer is 64kb. These issues could be indeed serious in certain
cases, but I still believe using protocol buffers is better than not.
I'd expect many more than these issues present in a custom parser.

regards,
Nikos
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Testing chrony seccomp support

[Nikos Mavrogiannopoulos]

On Mon, 2016-01-18 at 14:15 +0100, Miroslav Lichvar wrote:
> On Mon, Jan 18, 2016 at 11:02:44AM +0100, Nikos Mavrogiannopoulos
> wrote:
> > As Florian suggested it makes more sense to compartmentalize chrony
> > so
> > that only a small controlled part of it needs to run with seccomp.
> > My
> > recommendation, if you want to use libraries in the filtered code,
> > make
> > their authors aware of that, so that they document any changes in
> > the
> > used system calls, and if possible ask them to document the
> > existing
> > system calls used (e.g., similarly to:
> > http://www.gnutls.org/manual/html_node/Running-in-a-sandbox.html )
> 
> chronyd doesn't use libc for much more than that. There is memory
> allocation, reading/writing system clock, reading/writing/moving
> files, creating/connecting/binding sockets, receiving/sending
> packets, and select(). Name resolving is now out of the filter. The
> only other library that's currently used after the seccomp filter is
> loaded is freebl3 from NSS.
> 
> I guess some of that could be moved to the helper process. If only
> the most dangerous code (whatever that is) should run with seccomp,
> I'm not sure if there is a layer where a clean small cut could be
> made. I suspect the interface between the two processes would be huge
> and it would bloat the code significantly.

If you have complex structures to be transfered you may want to rely on
something automated to serialize/deserialize requests. That will
increase the code, but reduce the complexity. I've used protocol
buffers over unix sockets for that exact reason and I'm pretty happy
with it.

regards,
Nikos
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

seccomp support [was: Testing chrony seccomp support]

[Nikos Mavrogiannopoulos]

On Mon, 2016-01-18 at 09:51 -0600, Michael Catanzaro wrote:

> > I appreciate what you are trying to do, but those seccomp filters
> > totally break encapsulation.  I have no idea how to support this
> > properly, in a sustainable way.  It appears very difficult to do
> > this
> > for independently evolving libraries.
> 
> No matter what, any seccomp whitelist is doomed to break in the
> future
> if your program uses shared libraries (including glibc). I think
> seccomp filters can reasonably be used with a blacklist of syscalls,
> but not with a whitelist.

The issue is that blacklists are terrible from a security standpoint.
That means that every new obscure system call added to the kernel will
be available by default in your program.

> An anecdote: in WebKit (which has a seccomp filter sandbox not
> compiled
> by default, because it is unfinished and very fragile), the web
> process
> receives SIGSYS from seccomp when it calls open() or a related
> function, which it does not have permission to use; it then passes
> the
> filename of the file it wants to open via IPC to a broker process,
> which evaluates our filesystem policy, opens the file (if
> permissible),
> and sends the fd to the web process via a UNIX socket. This all goes
> awry if, in the web process's signal handler, malloc decides to call
> open(), triggering an infinite loop of SIGSYS handlers. So we have to
> open all files used by malloc (currently
> /proc/sys/vm/overcommit_memory
> and /sys/devices/system/cpu/online) and cache the fds in the web
> process before initializing seccomp filters. libseccomp could not
> help
> with that, since there are so many different ways to use seccomp; it
> doesn't know anything about our broker processs.

That does sound like a very fragile usage of seccomp indeed. It could
be solved of course by using IPC to open a file rather than relying on
the signal. In any case seccomp certainly requires a program to be
restructured or designed in a way to have a limited to syscall
requirements component to have seccomp enabled (e.g., only to glibc).
If you cannot have that then seccomp is probably not the answer. 

Then the question for programs wanting to use glibc and seccomp would
be, could libc keep the syscalls fixed for its wrapper of system calls,
or could we have filters which are applied to glibc's calls rather than
system calls? Otherwise the only remaining solution would be for
applications requiring seccomp to switch to thinner libc variants.

regards,
Nikos
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Testing chrony seccomp support

[Nikos Mavrogiannopoulos]

On Mon, 2016-01-18 at 12:51 +0100, Florian Weimer wrote:
> On 01/18/2016 11:02 AM, Nikos Mavrogiannopoulos wrote:
> 
> > As Florian suggested it makes more sense to compartmentalize chrony
> > so
> > that only a small controlled part of it needs to run with seccomp.
> > My
> > recommendation, if you want to use libraries in the filtered code,
> > make
> > their authors aware of that, so that they document any changes in
> > the
> > used system calls, and if possible ask them to document the
> > existing
> > system calls used (e.g., similarly to:
> > http://www.gnutls.org/manual/html_node/Running-in-a-sandbox.html )
> Interesting.  There is one huge caveat:
> > As well as an calls needed for memory allocation to work.
> 
> glibc malloc can basically call *anything*.  We don't know what the
> future will bring.  Currently, we use (off the top of my head, I
> haven't checked):
> * sbrk
> * mmap
> * mprotect
> * munmap
> * mremap
> * madvise
> * futex
> * open
> * read
> * close
> (In some cases, there is some sort of fallback, or errors are ignored
> and the optimization does not happen.)
> Future versions might reasonably use:
> * sched_getcpu
> * clone
> * clock_gettime
> * more open/read/close
> * readlink
> * whatever system calls are used for memory protection keys
> * whatever system calls are used for restartable sequences
> 
> I appreciate what you are trying to do, but those seccomp filters
> totally break encapsulation.  I have no idea how to support this
> properly, in a sustainable way.  It appears very difficult to do this
> for independently evolving libraries.

Could that be handled by libseccomp provided some input from glibc
(e.g., with some coordination, or glibc keeping the system calls it
uses fixed across minor updates)? Otherwise the alternative is for
programs not using seccomp and enabling all system calls to code
handling untrusted input.

regards,
Nikos
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Testing chrony seccomp support

[Nikos Mavrogiannopoulos]

On Mon, 2015-10-05 at 13:58 +0200, Miroslav Lichvar wrote:
> In chrony 2.2-pre1 was added support for system call filtering with
> the kernel seccomp facility. In chrony it's mainly useful to reduce
> the damage from attackers who can execute arbitrary code, e.g.
> prevent
> gaining the root privileges through a kernel vulnerability.
> 
> The rawhide chrony package is now compiled with the seccomp support,
> but the filtering is not enabled by default. The trouble is it has to
> cover all system calls needed in all possible configurations of
> chrony
> and all libraries it depends on, which is difficult and it may even
> change over time as the libraries are updated.

As Florian suggested it makes more sense to compartmentalize chrony so
that only a small controlled part of it needs to run with seccomp. My
recommendation, if you want to use libraries in the filtered code, make
their authors aware of that, so that they document any changes in the
used system calls, and if possible ask them to document the existing
system calls used (e.g., similarly to:
http://www.gnutls.org/manual/html_node/Running-in-a-sandbox.html )

regards,
Nikos
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

wml

[Nikos Mavrogiannopoulos]

Hi,
 Are there users of website meta-language using fedora? I use it for
some projects and thought it would be a useful addition. If you are a
user of it please do the review for it at:
https://bugzilla.redhat.com/show_bug.cgi?id=1295710

regards,
Nikos
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: orphaning radiusclient-ng

[Nikos Mavrogiannopoulos]

Hello Scott,
 I saw that you assumed maintainership of radiusclient-ng in devel.
This is a dead package since a decade now which has been replaced by
other software. Please orphan it so that it will be dropped from
fedora. If you have software which relies on it please use one of the
libraries replacing it (the latter is drop in replacement).


On Thu, 2015-10-08 at 10:46 +0200, Nikos Mavrogiannopoulos wrote:
> Hello,
>  I'll orphan radiusclient-ng with the purpose of dropping it from the
> next releases of Fedora. This is an old unmaintained library replaced
> by any of the following packages (the latter has an API compatible
> subpackage).
> * https://admin.fedoraproject.org/pkgdb/package/freeradius-client/
> * https://admin.fedoraproject.org/pkgdb/package/radcli
> 
> regards,
> Nikos
> 


--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

fedora notifications

[Nikos Mavrogiannopoulos]

Hi,
 I'm quite lost with the fedora notifications [0] for email. Do you
know which is the option to send me an email once a package is ready to
be pushed to stable? (i.e., when the waiting period has passed or the
feedback reached the threshold).

regards,
Nikos

[0]. https://apps.fedoraproject.org/notifications
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org