Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

[Lennart Poettering]

On Fr, 06.12.19 00:39, Kevin Kofler (kevin.kof...@chello.at) wrote:

> Lennart Poettering wrote:
> > No it does not protect against offline modification. That's why
> > dm-integrity exists after all.
>
> How do you want to modify an encrypted file system without being able to
> decrypt or encrypt anything?

If you know where stuff is located you can change individual blocks in
files. You are not going to know what you are changing them to, but
you can change it and traditional files will not detect that you did that.

Lennart

--
Lennart Poettering, Berlin
___
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: Allow comments and discussion even though an update was pushed to stable

[Mattia Verga via devel]

Il 06/12/19 07:34, Johannes Lips ha scritto:
> Hi all,
>
> I was recently bit by a bug, which was caused by a mismatch between 
> texlive-biblatex and biber. The technical side is not so important, only so 
> much that they need each other in a pretty specific version, which is not 
> reflected on the rpm level.
> What I found weird is that you can't comment on an update, which is already 
> pushed to stable. A lot of users are only hit by a bug, once it reaches 
> stable and then you don't have any possibility to highlight a bug report or 
> an issue with this update. I would like to have the possibility to add such 
> an information to an update, which introduced the issue.
That was requested and discussed long time ago in 
https://github.com/fedora-infra/bodhi/issues/2050

The rationale behind this was about the nonsense to have users 
commenting on an already pushed update, since this cannot be undone.

My opinion is that once an update is pushed to stable, new bugs should 
be reported in Bugzilla, not as comments in Bodhi. However there's an 
open discussion about restoring the previous behavior: 
https://github.com/fedora-infra/bodhi/issues/3748

> Also I would like to ask if it is possible for important updates, like the 
> texlive one to increase the stable karma. It really depends which mirrors you 
> are using and if you are unlucky the updates get pushed to stable, before it 
> reaches updates-testing for you and then again there's nothing to add, once 
> it's pushed.
>
The stable-karma and stable-days parameters can be set by the user in 
the web form or by CLI. By default stable-karma is set to 3, but it can 
be changed when creating the update.

Mattia


___
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

Fedora-Cloud-30-20191206.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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: Allow comments and discussion even though an update was pushed to stable

[Fabio Valentini]

On Fri, Dec 6, 2019, 07:35 Johannes Lips  wrote:

> Hi all,
>
> I was recently bit by a bug, which was caused by a mismatch between
> texlive-biblatex and biber. The technical side is not so important, only so
> much that they need each other in a pretty specific version, which is not
> reflected on the rpm level.
> What I found weird is that you can't comment on an update, which is
> already pushed to stable. A lot of users are only hit by a bug, once it
> reaches stable and then you don't have any possibility to highlight a bug
> report or an issue with this update.


I agree, this is definitely a regression with newer bodhi versions (5.0+ I
think). I also often get hit by bugs in updates that are either queued for
stable, or already pushed.

I would like to have the possibility to add such an information to an
> update, which introduced the issue.
> Also I would like to ask if it is possible for important updates, like the
> texlive one to increase the stable karma. It really depends which mirrors
> you are using and if you are unlucky the updates get pushed to stable,
> before it reaches updates-testing for you and then again there's nothing to
> add, once it's pushed.
>

What's even worse, some updates skip updates-testing altogether when enough
people give positive feedback on the koji builds fast enough. Then there's
literally *no* opportunity for "normal" users of updates-testing to provide
feedback in bodhi.

Fabio


> Thanks
> johannes
> ___
> 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
>
___
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

Allow comments and discussion even though an update was pushed to stable

[Johannes Lips]

Hi all,

I was recently bit by a bug, which was caused by a mismatch between 
texlive-biblatex and biber. The technical side is not so important, only so 
much that they need each other in a pretty specific version, which is not 
reflected on the rpm level.
What I found weird is that you can't comment on an update, which is already 
pushed to stable. A lot of users are only hit by a bug, once it reaches stable 
and then you don't have any possibility to highlight a bug report or an issue 
with this update. I would like to have the possibility to add such an 
information to an update, which introduced the issue.
Also I would like to ask if it is possible for important updates, like the 
texlive one to increase the stable karma. It really depends which mirrors you 
are using and if you are unlucky the updates get pushed to stable, before it 
reaches updates-testing for you and then again there's nothing to add, once 
it's pushed.

Thanks 
johannes
___
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: Review swap

[Vascom]

I can review it without swap.

пт, 6 дек. 2019 г. в 03:03, Jerry James :
>
> One of my upstreams picked up a new documentation dependency.  Who would like 
> to swap reviews?  This one should be quick and easy.
>
> python-sphinx-copybutton: https://bugzilla.redhat.com/show_bug.cgi?id=1780426
>
> Thank you,
> --
> Jerry James
> http://www.jamezone.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
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Nico Kadel-Garcia]

On Thu, Dec 5, 2019 at 9:02 AM John M. Harris Jr  wrote:

> Please don't recommend to anyone to use passwords for SSH. That is incredibly
> insecure, and if privileged users are using password-based SSH, that'll
> quickly lead to a serious compromise of your entire system, depending on the
> complexity of the password, of course, but still holds nothing to key-based
> authentication with the best password.

I was merely pointing out the options. Believe me, for SSH, I've seen
them some very astute and some quite foolish authentication practices
since I published the first public ports of ssh-1 and ssh-2 to SunOS
back in the 90's.

> > In common usage, very few people encrypt their home directories
> > separately from their basic disk image. It makes system management for
> > administrators or even a local root user very awkward. I could see it
> > for home directories in "/home", and it would only cost SSH key based
> > access, not ordinary password or Kerberos ticket based login. But it
> > sounds quite risky and destabilizing, much as the "kill dangling
> > processes when people log out". That  caused a lot of shock when it
> > was activated by default and started killing processes with no
> > logging. Let's not repeat a surprise like that and avoid killing SSH
> > key access by default.
>
> A bit off topic, but where is "kill danging processes when people log out"
> set? I've not experienced that anywhere.

Sorry, should have spelt that "dangling". systemd does so by default
based on a compile-time option, and for a time Fedora had it enabled
by default. After quite a furor, elected to disable this normally
unwelcome feture by default, See /etc/systemd/logind.conf.for the
"#KillUserProcesses=no" line.
___
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

[Bug 1777007] perl-libwww-perl-6.43 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-libwww-perl-6.43-1.fc3 |perl-libwww-perl-6.43-1.fc3
   |2   |2
   ||perl-libwww-perl-6.43-1.fc3
   ||1
 Resolution|--- |ERRATA
Last Closed|2019-11-27 14:20:05 |2019-12-06 05:43:48



--- Comment #5 from Fedora Update System  ---
perl-libwww-perl-6.43-1.fc31 has been pushed to the Fedora 31 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1774776] perl-libwww-perl-6.42 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-libwww-perl-6.42-1.fc3 |perl-libwww-perl-6.42-1.fc3
   |2   |2
   ||perl-libwww-perl-6.43-1.fc3
   ||1
 Resolution|--- |ERRATA
Last Closed|2019-11-27 14:19:53 |2019-12-06 05:43:49



--- Comment #7 from Fedora Update System  ---
perl-libwww-perl-6.43-1.fc31 has been pushed to the Fedora 31 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[389-devel] Please review: pr 50769 filter validation option fix

[William Brown]

https://pagure.io/389-ds-base/pull-request/50769
--
Sincerely,

William
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

[389-devel] 389 DS nightly 2019-12-06 - 96% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/12/06/report-389-ds-base-1.4.2.4-20191206git7301d43.fc31.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

Re: Unannounced library bump: thrift 0.10.0 -> 0.13.0

[Orion Poplawski]

On 12/5/19 9:45 AM, Fabio Valentini wrote:


Hi Orion,

Thanks for fixing the issues so quickly! I also hope my original
message didn't come across as too negative / critical. I just wanted
to give devel@ a short heads-up that something was broken in rawhide,
so it can be fixed in a timely manner, as well :)

Fabio


Not at all - thanks for the heads up.


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Chris Murphy]

On Thu, Dec 5, 2019 at 6:40 PM John M. Harris Jr  wrote:
>
> On Thursday, December 5, 2019 6:17:16 PM MST Chris Murphy wrote:

> > No it isn't. But as I've asked you for your definition of "support"
> > and you still haven't, and I've offered my own and you haven't
> > disputed it, I win. That's the short version because you have a track
> > record of not reading provided references. For the long version:
>
> There's nothing to "win". This isn't a competition. We're all on the same side
> here.

I am not confusing your persistent negativism and contrarianism with a
competition.

I win is tongue in cheek, of course we're all on the same side. Thank
you for saying so explicitly.

> My definition of "supported in Fedora" is.. supported in Fedora. You can do it
> in Fedora. Without modifying anything. In my DE, for example, I'd do that by
> pressing Alt + F1, the Super key, or click the KDE icon in the left of my
> primary screen's Panel, Leave -> Hibernate.

Using the word to be defined in the definition is insufficient and
vague. It's meaningless.

Feature existence is not support. The community members make a thing
supported, and it's only by community effort and prioritization that
features are supported. The track record of hibernation support, such
as it is, is best effort, but not blocking. If it breaks, Fedora ships
with it broken. There are flat out not enough resources to treat it
with any higher priority than this - it's not a new issue either.





>
> > > > b. It's disabled by kernel lockdown on UEFI Secure Boot systems.
> > >
> > >
> > >
> > > How so? What "kernel lockdown" are you referring to?
> >
> >
> > [1.097121] Lockdown: swapper/0: Hibernation is restricted; see man
> > kernel_lockdown.7
> >
> > And also the above kernel list email thread mentions it also. I'm
> > surprised you haven't heard of it, it's been around for quite a long
> > time as it's an obvious attack vector that obviates the point of
> > Secure Boot.
>
> I don't have a personal system that uses UEFI, much less "Secure Boot", so I
> things that affect those systems in Fedora, but not the versions of RHEL I
> work with, I have no reason to follow normally. I'll take a look, however.
> "Secure Boot" is a misnomer, by the way, and hibernation is not a security
> issue. Suspension is, but not hibernation.

All you're doing is demonstrating you don't understand the issues, or
maybe you don't care about the use case.

The hibernation image is not signed, thus malicious code could be
injected into the image, and loaded and executed upon resume. Contrary
to you merely saying things as if that makes them true, there is in
fact a security issue with hibernation that is incongruent with the
purpose of Secure Boot. It would be no different than allowing
arbitrary loading of unsigned kernel modules, which is also disallowed
by default on Secure Boot systems.

$ dmesg | grep -i lockdown
[0.00] Kernel is locked down from EFI secure boot; see man
kernel_lockdown.7
[1.097121] Lockdown: swapper/0: Hibernation is restricted; see man
kernel_lockdown.7
[1.438916] Lockdown: systemd: /dev/mem,kmem,port is restricted;
see man kernel_lockdown.7
[1.439911] Lockdown: systemd: BPF is restricted; see man kernel_lockdown.7

More lockdown is coming in 5.4.


> > > What are you talking about? You should have at least 1x RAM for swap
> > > whether you use hibernation or not. If you're having issues, you can
> > > adjust the swappiness as needed. There is no "effective loss of the
> > > system" involved.
> ...snip...
> > In the case where swap is used heavily, rather than incidentally, the
> > UX is atrocious. The resulting swap thrashing is ai bad the system is
> > functionally lost and it's completely reasonable for a user to force
> > power off.
>
> What are you suggesting the UX is atrocious for? Modifying the swappiness
> value? I have come across situations where a system without swap OOMs, and
> effectively freezes up as a result, causing the user to hard-boot the system,
> but I have never seen that with a system where swap was at least 1x the amount
> of RAM.

The thread I cited contains an example of a consistently reproducible
unprivileged compile that acts like a fork bomb that will take down
the system, including one with swap size = 1x RAM. It reproduces on
baremetal and in a VM. The time to OOM providing some chance of
recovery is *extended* the bigger swap is. Thus the problem is
actually made worse.

> > There's actual background study and work to be done before a release
> > criterion is accepted. Saying things doesn't make them true. The
> > criterion itself needs to be written, test cases produced and sanity
> > checked, and perhaps most importantly: who will be fixing the blocker
> > bugs? You need willing people to be available from multiple teams,
> > each having enough resources to ensure it gets highly escalated fixes.
>
> It doesn't really make any sense to dismiss this. If it's deemed necessary for
> there 

Re: Should we discontinue the Python Classroom Lab?

[Kevin Fenzi]

On Thu, Dec 05, 2019 at 04:42:46PM -0700, John M. Harris Jr wrote:
> On Thursday, December 5, 2019 1:05:38 PM MST Daniel Walsh wrote:
> > On 12/5/19 9:55 AM, John M. Harris Jr wrote:
> > 
> > > On Thursday, December 5, 2019 3:44:50 AM MST Miro Hrončok wrote:
> > > 
> > >>   - Docker is broken
> > >>   
> > >> - one of the main ideas was to produce a Docker image
> > >> - the Docker instructions on the download page [4] are not working
> > >> - not even when replaced with podman
> > >> - I have no idea how to fix it
> > >> - I know no way to upload to official dockerhub [5]
> > > 
> > > What's wrong with the packaged version of Docker?
> > >
> > >
> > 
> > It does not exists in Fedora 31.  What is the issue with Podman support?
> 
> I didn't know it was removed, and I don't know what "Podman" is. Is that a 
> Docker clone?

It's a mostly compatible command line wise with the old docker, no daemon, 
OCI (open container initiative) comlpiant container engine.
https://podman.io/

> Why in the world was Docker removed? Docker is the most popular container 
> technology, so if we must embrace the "container" systems, why not include 
> the 
> most popular in Fedora?

Because Docker, inc decided to use 'docker' for their commercial
offerings and split off the open source version as 'moby'. 

moby is packaged and available in Fedora, but IMHO podman is much
better. No big deamon needed, no root needed (depending on what you are
doing), very responsive upstream.

(I'm sure dwalsh or others will correct me if I am off on any of the
above)

kevin


signature.asc
Description: PGP signature
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[John M. Harris Jr]

On Thursday, December 5, 2019 6:17:16 PM MST Chris Murphy wrote:
> On Thu, Dec 5, 2019 at 4:49 PM John M. Harris Jr 
> wrote:
> >
> >
> > On Thursday, December 5, 2019 1:40:02 PM MST Chris Murphy wrote:
> > 
> > > Hibernation is out of scope to rely on, let alone make a default, for
> > > at least the following reasons:
> > > a. It's not sufficiently well supported upstream for regressions that
> > > may appear in new kernels, and not supported by the Fedora kernel
> > > team.
> >
> >
> >
> > I'm not sure who told you this, but that's not the case. Hibernation is
> > supported in Fedora.
> 
> 
> No it isn't. But as I've asked you for your definition of "support"
> and you still haven't, and I've offered my own and you haven't
> disputed it, I win. That's the short version because you have a track
> record of not reading provided references. For the long version:

There's nothing to "win". This isn't a competition. We're all on the same side 
here.

My definition of "supported in Fedora" is.. supported in Fedora. You can do it 
in Fedora. Without modifying anything. In my DE, for example, I'd do that by 
pressing Alt + F1, the Super key, or click the KDE icon in the left of my 
primary screen's Panel, Leave -> Hibernate.

> > > b. It's disabled by kernel lockdown on UEFI Secure Boot systems.
> >
> >
> >
> > How so? What "kernel lockdown" are you referring to?
> 
> 
> [1.097121] Lockdown: swapper/0: Hibernation is restricted; see man
> kernel_lockdown.7
> 
> And also the above kernel list email thread mentions it also. I'm
> surprised you haven't heard of it, it's been around for quite a long
> time as it's an obvious attack vector that obviates the point of
> Secure Boot.

I don't have a personal system that uses UEFI, much less "Secure Boot", so I 
things that affect those systems in Fedora, but not the versions of RHEL I 
work with, I have no reason to follow normally. I'll take a look, however. 
"Secure Boot" is a misnomer, by the way, and hibernation is not a security 
issue. Suspension is, but not hibernation.

> > What are you talking about? You should have at least 1x RAM for swap
> > whether you use hibernation or not. If you're having issues, you can
> > adjust the swappiness as needed. There is no "effective loss of the
> > system" involved.
...snip...
> In the case where swap is used heavily, rather than incidentally, the
> UX is atrocious. The resulting swap thrashing is ai bad the system is
> functionally lost and it's completely reasonable for a user to force
> power off.

What are you suggesting the UX is atrocious for? Modifying the swappiness 
value? I have come across situations where a system without swap OOMs, and 
effectively freezes up as a result, causing the user to hard-boot the system, 
but I have never seen that with a system where swap was at least 1x the amount 
of RAM.

> > > d. There's no release criterion. Therefore the project wouldn't block
> > > release on any discovered bugs. Serious bugs would likely lead to
> > > reverting any use of hibernation by default, and so it's not at all
> > > likely it'll become supported by default.
> >
> >
> >
> > Blockers are dynamic. We can make new blockers if we need them.
> 
> 
> There's actual background study and work to be done before a release
> criterion is accepted. Saying things doesn't make them true. The
> criterion itself needs to be written, test cases produced and sanity
> checked, and perhaps most importantly: who will be fixing the blocker
> bugs? You need willing people to be available from multiple teams,
> each having enough resources to ensure it gets highly escalated fixes.

It doesn't really make any sense to dismiss this. If it's deemed necessary for 
there to be a blocker, we can make a new blocker. That's a non-issue.

-- 
John M. Harris, Jr.
Splentity

___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Chris Murphy]

On Thu, Dec 5, 2019 at 4:49 PM John M. Harris Jr  wrote:
>
> On Thursday, December 5, 2019 1:40:02 PM MST Chris Murphy wrote:
> > Hibernation is out of scope to rely on, let alone make a default, for
> > at least the following reasons:
> > a. It's not sufficiently well supported upstream for regressions that
> > may appear in new kernels, and not supported by the Fedora kernel
> > team.
>
> I'm not sure who told you this, but that's not the case. Hibernation is
> supported in Fedora.

No it isn't. But as I've asked you for your definition of "support"
and you still haven't, and I've offered my own and you haven't
disputed it, I win. That's the short version because you have a track
record of not reading provided references. For the long version:

https://lists.fedoraproject.org/archives/list/ker...@lists.fedoraproject.org/message/TLTA6HAYJWQYHV3ZHFXUIXM4IJVWBEJJ/


> > b. It's disabled by kernel lockdown on UEFI Secure Boot systems.
>
> How so? What "kernel lockdown" are you referring to?

[1.097121] Lockdown: swapper/0: Hibernation is restricted; see man
kernel_lockdown.7

And also the above kernel list email thread mentions it also. I'm
surprised you haven't heard of it, it's been around for quite a long
time as it's an obvious attack vector that obviates the point of
Secure Boot.



>
> > c. Resource requirements are excessive, there's no dynamic allocation
> > so to be safe you need to allocate a minimum of 1x RAM for a swap
> > partition used for a hibernation image. As a consequence, there's now
> > an excessive amount of relatively slow swap which can result in swap
> > thrashing and the effective loss of the system. See "Better
> > interactivity in low-memory situations "
> > https://pagure.io/fedora-workstation/issue/98
>
> What are you talking about? You should have at least 1x RAM for swap whether
> you use hibernation or not. If you're having issues, you can adjust the
> swappiness as needed. There is no "effective loss of the system" involved.

Already discussed, with examples, in:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XUZLHJ5O32OX24LG44R7UZ2TMN6NY47N/

And also a proposal to drop swap on a physical drive in favor of swap
on ZRAM which Fedora does on Live media boot, and for some time on
netinstall/DVD boot.
https://pagure.io/fedora-workstation/issue/82#comment-587914
https://pagure.io/fedora-workstation/issue/98#comment-590690
https://bugzilla.redhat.com/show_bug.cgi?id=1731978

In the case where swap is used heavily, rather than incidentally, the
UX is atrocious. The resulting swap thrashing is ai bad the system is
functionally lost and it's completely reasonable for a user to force
power off.

>
> > d. There's no release criterion. Therefore the project wouldn't block
> > release on any discovered bugs. Serious bugs would likely lead to
> > reverting any use of hibernation by default, and so it's not at all
> > likely it'll become supported by default.
>
> Blockers are dynamic. We can make new blockers if we need them.

There's actual background study and work to be done before a release
criterion is accepted. Saying things doesn't make them true. The
criterion itself needs to be written, test cases produced and sanity
checked, and perhaps most importantly: who will be fixing the blocker
bugs? You need willing people to be available from multiple teams,
each having enough resources to ensure it gets highly escalated fixes.


--
Chris Murphy
___
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: Orphaned packages looking for new maintainers

[Sérgio Basto]

Hi, 

How I produce the results of orphans-2019-12-02.txt ? or please could
you update and upload orphans-2019-12-06.txt to see what we still need
for js-jquery , etc.

Thank you.

On Mon, 2019-12-02 at 19:15 +0100, Miro Hrončok wrote:
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know
> for sure
> that the package should be retired, please do so now with a proper
> reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 
> Note: If you received this mail directly you (co)maintain one of the
> affected
> packages or a package that depends on one. Please adopt the affected
> package or
> retire your depending package to avoid broken dependencies, otherwise
> your
> package will be retired when the affected package gets retired.
> 
> Request package ownership via releng issues:
> https://pagure.io/releng/issues
> 
> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2019-12-02.txt
> grep it for your FAS username and follow the dependency chain.
> 
>  Package  (co)maintainers   S
> tatus Change
> =
> ===
> ExchangeIRorphan   2
> weeks ago
> FUR   orphan   3
> weeks ago
> airsnort  orphan   3
> weeks ago
> apache-logging-parent mizdebsk, orphan 2
> weeks ago
> apache-mime4j orphan   5
> weeks ago
> apt-cacher-ng orphan   2
> weeks ago
> archaius  orphan   2
> weeks ago
> archmage  lbazan, orphan   1
> weeks ago
> audit-viewer  mitr, orphan 1
> weeks ago
> avalon-logkit jerboaa, mizdebsk, orphan1
> weeks ago
> base64coder   jcapik, mizdebsk, orphan 3
> weeks ago
> batik jvanek, mizdebsk, orphan 3
> weeks ago
> buildnumber-maven-plugin  orphan   1
> weeks ago
> bval  orphan   2
> weeks ago
> camotics  orphan   2
> weeks ago
> cduce orphan   2
> weeks ago
> clapham   orphan   2
> weeks ago
> classmate lef, orphan  4
> weeks ago
> cli-parserlef, orphan  4
> weeks ago
> cpptasks  orphan   0
> weeks ago
> csstidy   orphan   2
> weeks ago
> delve go-sig, orphan   2
> weeks ago
> dzen2 bstinson, dcantrel, fale,0
> weeks ago
>lupinix, orphan
> eclipse-anyedit   eclipse-sig, orphan, swagiaal2
> weeks ago
> eclipse-avr   orphan   2
> weeks ago
> eclipse-cdt   akurtakov, eclipse-sig,  5
> weeks ago
>jjohnstn, kdaniel, orphan,
>rgrunber
> eclipse-checkstyleakurtakov, eclipse-sig, orphan   2
> weeks ago
> eclipse-color-theme   eclipse-sig, orphan  2
> weeks ago
> eclipse-dltk  akurtakov, eclipse-sig,  2
> weeks ago
>kdaniel, orphan, rgrunber
> eclipse-egit  akurtakov, arobinso, eclipse-2
> weeks ago
>sig, jerboaa, jjohnstn,
>kdaniel, nguzman, orphan,
>rgrunber
> eclipse-emf   akurtakov, eclipse-sig,  2
> weeks ago
>jjohnstn, kdaniel, orphan,
>rgrunber
> eclipse-epic  eclipse-sig, orphan  2
> weeks ago
> eclipse-gef   akurtakov, eclipse-sig,  2
> weeks ago
>kdaniel, orphan, rgrunber
> eclipse-launchbar eclipse-sig, orphan, sopotc  4
> weeks ago
> eclipse-license   eclipse-sig, orphan  2
> weeks ago
> eclipse-m2e-antlr eclipse-sig, mizdebsk, orphan2
> weeks ago
> eclipse-m2e-core  eclipse-sig, galileo,2
> weeks ago
>mizdebsk, orphan
> eclipse-m2e-cxf   

Review swap

[Jerry James]

One of my upstreams picked up a new documentation dependency.  Who would
like to swap reviews?  This one should be quick and easy.

python-sphinx-copybutton:
https://bugzilla.redhat.com/show_bug.cgi?id=1780426

Thank you,
-- 
Jerry James
http://www.jamezone.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

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

[John M. Harris Jr]

On Thursday, December 5, 2019 12:46:51 PM MST Chris Murphy wrote:
> Therefore the feature is a no op for most users, who are unlikely to
> enable file system discards using either method.

This is Fedora, not Sugar on a Stick. Our users are not ignorant of modifying 
fstab, or similar. I wouldn't be so quick to assume that users wouldn't change 
the mount options, especially as there are guides online that suggest adding 
'discard'.

-- 
John M. Harris, Jr.
Splentity

___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[John M. Harris Jr]

On Thursday, December 5, 2019 3:02:48 PM MST Chris Murphy wrote:
> On Thu, Dec 5, 2019 at 4:03 AM Marius Schwarz 
> wrote:
 
> 
> > With FDE running and "Suspend-to-disk" selected in your screensafer
> > settings, you get asked for your password on hw wakeup before your
> > system gets back running. If someone wants to use such things, he
> > already can.
> 
> 
> FDE depends on initramfs and plymouth to present the UI for volume
> unlock passphrase. That stack is limited, and presents numerous UI/UX,
> a11y, i18n, and other problems , that must be considered in the
> evaluation to enable it by default. And that is the context, how to
> better secure user data by default. The mandate is not to make it
> perfect. It's to do better.

There is really no UI/UX issue. It just needs to ask for a password for a key 
to decrypt. That's it. The UI is limited to either:
1, without Plymouth: A line in a framebuffer asking you to enter a password
2, with Plymouth: A box in the center of your screen that shows circles as you 
enter keys, expecting you to enter a password for a key.

-- 
John M. Harris, Jr.
Splentity

___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[John M. Harris Jr]

On Thursday, December 5, 2019 1:40:02 PM MST Chris Murphy wrote:
> Hibernation is out of scope to rely on, let alone make a default, for
> at least the following reasons:
> a. It's not sufficiently well supported upstream for regressions that
> may appear in new kernels, and not supported by the Fedora kernel
> team.

I'm not sure who told you this, but that's not the case. Hibernation is 
supported in Fedora.

> b. It's disabled by kernel lockdown on UEFI Secure Boot systems.

How so? What "kernel lockdown" are you referring to?

> c. Resource requirements are excessive, there's no dynamic allocation
> so to be safe you need to allocate a minimum of 1x RAM for a swap
> partition used for a hibernation image. As a consequence, there's now
> an excessive amount of relatively slow swap which can result in swap
> thrashing and the effective loss of the system. See "Better
> interactivity in low-memory situations "
> https://pagure.io/fedora-workstation/issue/98

What are you talking about? You should have at least 1x RAM for swap whether 
you use hibernation or not. If you're having issues, you can adjust the 
swappiness as needed. There is no "effective loss of the system" involved.

> d. There's no release criterion. Therefore the project wouldn't block
> release on any discovered bugs. Serious bugs would likely lead to
> reverting any use of hibernation by default, and so it's not at all
> likely it'll become supported by default.

Blockers are dynamic. We can make new blockers if we need them.

-- 
John M. Harris, Jr.
Splentity

___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[John M. Harris Jr]

On Thursday, December 5, 2019 9:26:09 AM MST Przemek Klosowski via devel 
wrote:
> On 12/4/19 6:59 PM, John M. Harris Jr wrote:
> > On Wednesday, December 4, 2019 12:38:20 PM MST Przemek Klosowski via devel
> > 
> > wrote:
> >> - stolen/lost laptop:  I think this is the most important one for most
> >> people; it is mitigaged by a trusted-network-based decryption, unless
> >> the device is in unencrypted sleep mode and the new 'beneficial owner'
> >> manages to read the disk before the system goes down.
> > 
> > That may be the case for home users, but not for businesses. Let's take
> > this example. Employee A has files from a given project, but Employee B
> > doesn't have access to that project. Employee B is malicious, and takes
> > Employee A's laptop, gets it on the network, it unencrypts itself and
> > then takes it.
> Defending against threat model allowing physical access and malicious
> insiders, who e.g. install a screen/keyboard capturing camera in the
> target office, is an entirely different ballgame, requiring multi-factor
> authentication, etc. --- and even those are not infallible (c.f. wikileaks).

You're conflating issues. For example, Snowden was an issue of trust, the 
human element. He had access to the data he removed. I'm not talking about 
that, because that is out of scope.

> >> - someone breaks into your home/office/hotel room and extracts the data:
> >> important to some people but not very common scenario.
> > 
> > This is important to most businesses.
> 
> Same argument as above. Again, we're talking about taking care of the
> low hanging fruit like hard disks stripped from equipment and sold on Ebay.

The argument from above does not apply here. You're talking about physical 
security, which is out of scope. I'm talking about software security.

-- 
John M. Harris, Jr.
Splentity

___
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: Should we discontinue the Python Classroom Lab?

[John M. Harris Jr]

On Thursday, December 5, 2019 1:05:38 PM MST Daniel Walsh wrote:
> On 12/5/19 9:55 AM, John M. Harris Jr wrote:
> 
> > On Thursday, December 5, 2019 3:44:50 AM MST Miro Hrončok wrote:
> > 
> >>   - Docker is broken
> >>   
> >> - one of the main ideas was to produce a Docker image
> >> - the Docker instructions on the download page [4] are not working
> >> - not even when replaced with podman
> >> - I have no idea how to fix it
> >> - I know no way to upload to official dockerhub [5]
> > 
> > What's wrong with the packaged version of Docker?
> >
> >
> 
> It does not exists in Fedora 31.  What is the issue with Podman support?

I didn't know it was removed, and I don't know what "Podman" is. Is that a 
Docker clone?

Why in the world was Docker removed? Docker is the most popular container 
technology, so if we must embrace the "container" systems, why not include the 
most popular in Fedora?

-- 
John M. Harris, Jr.
Splentity

___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Kevin Kofler]

Lennart Poettering wrote:
> No it does not protect against offline modification. That's why
> dm-integrity exists after all.

How do you want to modify an encrypted file system without being able to 
decrypt or encrypt anything?

Kevin Kofler
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[John M. Harris Jr]

On Thursday, December 5, 2019 5:32:55 AM MST Lennart Poettering wrote:
> > Where is the advantage of homed, considering, that only encrypting
> > /home, is a major security flaw by itself. All your goals are
> > already there and it's more useful and secure too :) I really have a
> > problem understanding why you wanne implement a security flaw and
> > call it "better".
> 
> 
> Locking down the OS itself and locking down the user's home are two
> different things, because OS integrity should be bound to different
> mechanisms than user data encryption. (i.e. OS integrity should be
> bound to vendor trust or TPM, while user data should be bound to
> user's security credentials).

I could not disagree more. That would be fine if the trust were the user or 
the organization that owns the machine, but not vendor trust or anything of 
the like. It's not some third party's system, it's the user or organization's. 
Additionally, it's much easier to get a third party to sign something for you 
than to get the users themselves, or an organization, to sign it.

> > If you wanne improve security, please focus on userfriendlyneess for
> > things like "disabling unused usb ports"/"whitelist for usb
> > ids"/"insecure Highspeed USB network adapter detection"  same for any
> > plugable port you have in your hw. And last, but not least, "motherboard
> > serial number validation on wakeup" to counter the switch of hw
> > components.
> 
> Uh, locking down USB like that doesn't really work. USB has no
> mechanism for recognizing devices securely, which means any whitelist
> is pointless because any device can claim to be whatever it wants to
> be. (And yes, it would be great if we could be a bit more secure
> there, but it's an orthogonal problem)

Well, that's not entirely true. For example, while devices could easily give a 
false VID and PID, even just limiting that would be a useful feature, because 
it'd limit the USB functionality of the system (only the modules Linux maps 
those VID/PID combos to would be available).

-- 
John M. Harris, Jr.
Splentity

___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Chris Murphy]

On Thu, Dec 5, 2019 at 4:03 AM Marius Schwarz  wrote:

> With FDE running and "Suspend-to-disk" selected in your screensafer
> settings, you get asked for your password on hw wakeup before your
> system gets back running. If someone wants to use such things, he
> already can.

FDE depends on initramfs and plymouth to present the UI for volume
unlock passphrase. That stack is limited, and presents numerous UI/UX,
a11y, i18n, and other problems , that must be considered in the
evaluation to enable it by default. And that is the context, how to
better secure user data by default. The mandate is not to make it
perfect. It's to do better.

> Where is the advantage of homed, considering, that only encrypting
> /home, is a major security flaw by itself. All your goals are already
> there and it's more useful and secure too :) I really have a problem
> understanding why you wanne implement a security flaw and call it "better".

Please read "LUKS by default"
https://pagure.io/fedora-workstation/issue/82

If you read the whole thing, you should come to understand why the
initial agreement to implement full disk encryption was suspended, and
also that this issue has a history proving it is being taken seriously
and deliberately.


-- 
Chris Murphy
___
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: Should we discontinue the Python Classroom Lab?

[Miro Hrončok]

On 05. 12. 19 21:05, Daniel Walsh wrote:

On 12/5/19 9:55 AM, John M. Harris Jr wrote:

On Thursday, December 5, 2019 3:44:50 AM MST Miro Hrončok wrote:

   - Docker is broken
 - one of the main ideas was to produce a Docker image
 - the Docker instructions on the download page [4] are not working
 - not even when replaced with podman
 - I have no idea how to fix it
 - I know no way to upload to official dockerhub [5]

What's wrong with the packaged version of Docker?


It does not exists in Fedora 31.  What is the issue with Podman support?


I suppose the image does not exist in the registry at all.

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

[Bug 1744690] [RFE] EPEL8 branch of perl-Plack

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #13 from Fedora Update System  ---
FEDORA-EPEL-2019-5d2caf321b has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-5d2caf321b

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

[Chris Murphy]

On Thu, Dec 5, 2019 at 5:07 AM Marius Schwarz  wrote:
>
> Hi,
>
> Am 25.11.19 um 22:59 schrieb Samuel Sieb:
> >
> > Steps 1 - 4 are not benefits, they are workarounds to critical system
> > utilities required by this change.  I don't understand why this change
> > is necessary at all.  It only affects local logins and if someone
> > wants to have an empty password, why make it so difficult?  It's their
> > choice.  It's not like Fedora has any default logins with empty
> > passwords, the user has to make their own.
>
> I know at least two real exiting none nerd users, who will agree with
> you, as they use FullDiskEnc and no further passwords to Login after boot.
>
> Which would be impossible if the changes will be made. I personally have
> only on scenario to offer:
>
> A tablet pc is booted directly into the desktop, as any other tablet
> (android or ipad) will do.

If you set a passphrase for full disk encryption (or only /home mount
point, using custom partitioning)  in the installer, and use the same
passphrase when running GNOME Initial Setup, and then set autologin
for that user, you will get the behavior you describe.


-- 
Chris Murphy
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Chris Murphy]

On Thu, Dec 5, 2019 at 8:57 AM Marius Schwarz  wrote:
>
> Am 05.12.19 um 13:32 schrieb Lennart Poettering:
>
> Well, the way this has been traditionally done is that the lock screen
> is displayed by a program running under the user's identity and that
> the user's data is entirely unlocked the entire time during suspend,
>
> That depends on what you have chosen "sleep" or "hibernate" .
>
> If the device just sleeps, your data is unprotected, as the key could be in 
> your still powered memory bank.
>
> With hibernation, as far as I have seen it with my devices, the hw stops 
> entirely after saving the memory state to disk,
> an encrypted disk I may add. On boot, it asks for the decryption keys as it 
> would normally do, finds the hibernate signature
> on swap ( i presume / which is also encrypted ) and restores memory. I don't 
> see a way for an attack here.

Hibernation is out of scope to rely on, let alone make a default, for
at least the following reasons:
a. It's not sufficiently well supported upstream for regressions that
may appear in new kernels, and not supported by the Fedora kernel
team.
b. It's disabled by kernel lockdown on UEFI Secure Boot systems.
c. Resource requirements are excessive, there's no dynamic allocation
so to be safe you need to allocate a minimum of 1x RAM for a swap
partition used for a hibernation image. As a consequence, there's now
an excessive amount of relatively slow swap which can result in swap
thrashing and the effective loss of the system. See "Better
interactivity in low-memory situations "
https://pagure.io/fedora-workstation/issue/98
d. There's no release criterion. Therefore the project wouldn't block
release on any discovered bugs. Serious bugs would likely lead to
reverting any use of hibernation by default, and so it's not at all
likely it'll become supported by default.


-- 
Chris Murphy
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Andreas Tunek]

On Thu, 5 Dec 2019, 02:11 John M. Harris Jr,  wrote:

>
>
> The user experience is nothing like data loss. The users are not stupid.
> It's
> fine that the keyboard layout for initramfs is only updated when initramfs
> is
> rebuilt. People don't change their primary keyboard layout very often. I
> have
> to disagree, that this is a "hostile user experience". If you want to fix
> this, the fix is simple. Rebuild initramfs when the system-wide keyboard
> layout is changed.
>
> John M. Harris, Jr.
> Splentity
>
>
I change my keyboard layout several times every hour.



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

[Bug 1761447] Fusioninventory-agent dependency problems

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |CURRENTRELEASE
Last Closed||2019-12-05 20:17:52



--- Comment #6 from Emmanuel Seyman  ---
fusioninventory-agent is now in stable and can be installed without problems.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: Should we discontinue the Python Classroom Lab?

[Daniel Walsh]

On 12/5/19 9:55 AM, John M. Harris Jr wrote:
> On Thursday, December 5, 2019 3:44:50 AM MST Miro Hrončok wrote:
>>   - Docker is broken
>> - one of the main ideas was to produce a Docker image
>> - the Docker instructions on the download page [4] are not working
>> - not even when replaced with podman
>> - I have no idea how to fix it
>> - I know no way to upload to official dockerhub [5]
> What's wrong with the packaged version of Docker?
>
It does not exists in Fedora 31.  What is the issue with Podman support?

___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Chris Murphy]

On Thu, Dec 5, 2019 at 8:04 AM Lennart Poettering  wrote:
> If you use LUKS/dm-crypt without dm-integrity and you have a clue
> where things are located then you can change files without anything
> being able to detect that. (On btrfs you might have some luck, since
> it has data checksumming, but ext4 and other traditional file systems
> do not).

xxhash, sha256, and blake2 coming to Btrfs in kernel 5.5, with online
conversion between them.


> And it's easier to figure out where stuff is located then you might
> think since we live in a world where people use SSDs and mount file
> systems with "discard", so that what are used blocks and what are free
> blocks is propagated to the underlying device. Moreover file systems
> write in certain patterns, i.e. try to keep large files in one stream
> together, put files in the same directories adjacent to each other and
> so on, and are usually roughly reproducible.

Fedora install time default for LUKS encrypted volumes is to unlocked
with cryptsetup open --allow-discards, which is set in /etc/crypttab
by using the discard option. This is since Fedora 27.
https://fedoraproject.org/wiki/Changes/EnableTrimOnDmCrypt

However, the installer doesn't enable the discard mount option for any
file system in /etc/fstab, and fstrim.timer is disabled by default.
Therefore the feature is a no op for most users, who are unlikely to
enable file system discards using either method.

-- 
Chris Murphy
___
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: el6_10?

[Kevin Fenzi]

On Thu, Dec 05, 2019 at 06:38:27PM +, Dave Dykstra wrote:
> Why are el6 builds now showing up as el6_10?  For example:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=39443320

Because Red Hat pushed an update that changed the dist tag to that. :( 

> In order to do fedpkg update I had to change the el6 in the first line
> to el6_10 by hand, otherwise I get an error
> Could not execute update: Could not generate update request: Build does 
> not exist: singularity-3.5.1-1.1.el6

Yeah. 

So, we could try and override this, or adjust things to just deal with
it. 

I really wish they hadn't pushed this out as an update. ;( 

kevin


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@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-devel@lists.fedoraproject.org

[EPEL-devel] el6_10?

[Dave Dykstra]

Why are el6 builds now showing up as el6_10?  For example:
https://koji.fedoraproject.org/koji/taskinfo?taskID=39443320

In order to do fedpkg update I had to change the el6 in the first line
to el6_10 by hand, otherwise I get an error
Could not execute update: Could not generate update request: Build does not 
exist: singularity-3.5.1-1.1.el6

Dave
___
epel-devel mailing list -- epel-devel@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-devel@lists.fedoraproject.org

Re: (thinking about) unretiring xmlbeans

[Zbigniew Jędrzejewski-Szmek]

On Thu, Dec 05, 2019 at 05:05:46PM +, Mat Booth wrote:
> On Thu, 5 Dec 2019 at 12:52, Zbigniew Jędrzejewski-Szmek 
> wrote:
> 
> > xmlbeans [1,2] got retired because of lack of maitainers.
> > It's used by diffoscope now, so I'm thinking about adopting it.
> > Any major reasons not to? Fedora was at 2.6.0, upstream is now at
> > 3.1.0, so it'd be definitely some effort to update...
> >
> > [1] https://xmlbeans.apache.org/
> > [2] https://src.fedoraproject.org/rpms/xmlbeans
> >
> 
> 
> Huh, I thought this project was retired upstream I'm curious what you
> need it for

It seems to be alive again, latest version was released a few months ago
(https://xmlbeans.apache.org/download/).
It's now under under the apache poi umbrella.

Some of the scripts in xmlbeans-scripts are used by diffoscope.
I don't know the details.

Zbyszek
___
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: (thinking about) unretiring xmlbeans

[Mat Booth]

On Thu, 5 Dec 2019 at 12:52, Zbigniew Jędrzejewski-Szmek 
wrote:

> xmlbeans [1,2] got retired because of lack of maitainers.
> It's used by diffoscope now, so I'm thinking about adopting it.
> Any major reasons not to? Fedora was at 2.6.0, upstream is now at
> 3.1.0, so it'd be definitely some effort to update...
>
> [1] https://xmlbeans.apache.org/
> [2] https://src.fedoraproject.org/rpms/xmlbeans
>


Huh, I thought this project was retired upstream I'm curious what you
need it for

-- 
Mat Booth
http://fedoraproject.org/get-fedora
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Kevin Fenzi]

On Thu, Dec 05, 2019 at 07:02:08AM -0700, John M. Harris Jr wrote:
> On Thursday, December 5, 2019 5:41:44 AM MST Nico Kadel-Garcia wrote:
...snip...
> > In common usage, very few people encrypt their home directories
> > separately from their basic disk image. It makes system management for
> > administrators or even a local root user very awkward. I could see it
> > for home directories in "/home", and it would only cost SSH key based
> > access, not ordinary password or Kerberos ticket based login. But it
> > sounds quite risky and destabilizing, much as the "kill dangling
> > processes when people log out". That  caused a lot of shock when it
> > was activated by default and started killing processes with no
> > logging. Let's not repeat a surprise like that and avoid killing SSH
> > key access by default.
> 
> A bit off topic, but where is "kill danging processes when people log out" 
> set? I've not experienced that anywhere.

It's set in /etc/systemd/logind.conf, but it defaults to off in fedora. 

It was enabled for a short time in rawhide, then disabled.

kevin


signature.asc
Description: PGP signature
___
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: Bohdi / Create New Update - I miss the field Builds

[Fabio Valentini]

On Thu, Dec 5, 2019 at 5:53 PM Martin Gansser  wrote:
>
> ok, i see, they have moved the builds field to the top.
> sorry for the yelp.

Can I suggest that you also not fill the "Name" field with just the
name of the updated package?
Even the automatically generated default value if you leave it empty
(the list of builds) is more useful than just "NAME".

Thanks,
Fabio

> Regards
> Martin
> ___
> 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
___
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: Bohdi / Create New Update - I miss the field Builds

[Martin Gansser]

ok, i see, they have moved the builds field to the top.
sorry for the yelp.

Regards
Martin
___
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: Bohdi / Create New Update - I miss the field Builds

[Pierre-Yves Chibon]

On Thu, Dec 05, 2019 at 04:44:34PM -, Martin Gansser wrote:
> I mean this field [1]
> 
> [1] https://martinkg.fedorapeople.org/ErrorReports/bohdi/bohdi.png

https://bodhi.fedoraproject.org/updates/new It is now at the very top of the
page addressing some of the feedback the previous version of bodhi raised.


Pierre
___
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: Bohdi / Create New Update - I miss the field Builds

[Fabio Valentini]

On Thu, Dec 5, 2019 at 5:45 PM Martin Gansser  wrote:
>
> I mean this field [1]
>
> [1] https://martinkg.fedorapeople.org/ErrorReports/bohdi/bohdi.png

The "builds" field has been moved to the top of the page again
(thanks, bodhi maintainers!).
If it doesn't show up for you, maybe a hard refresh of the page
(usually Ctrl-Shift-R) should do the trick.

Fabio

> ___
> 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
___
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: Bohdi / Create New Update - I miss the field Builds

[Clement Verna]

On Thu, 5 Dec 2019 at 17:45, Martin Gansser 
wrote:

> I mean this field [1]
>
> [1] https://martinkg.fedorapeople.org/ErrorReports/bohdi/bohdi.png


Hi Martin,

A new version of Bodhi was deployed yesterday. Can you clean your browser
cache and reload the page ?

And let us know if that helps :-)


>
> ___
> 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
>
___
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: Unannounced library bump: thrift 0.10.0 -> 0.13.0

[Fabio Valentini]

On Thu, Dec 5, 2019 at 4:50 AM Orion Poplawski  wrote:
>
> On 12/4/19 3:44 PM, Fabio Valentini wrote:
> > Hi everybody,
> >
> > The "thrift" package was updated in rawhide and changed the name of
> > its library (which is oddly versioned anyway, and the "main" package
> > ships *.so files ???)
>
> My apologies.  This was my fist time updating thrift and I was unaware
> that it used that unfortunate shared library versioning scheme.
>
> > At least gnuradio needs to be rebuilt for the new version (if it
> > supports the new library version? it's not a simple SONAME bump, since
> > the libraries aren't versioned).
>
> Well, it's a SONAME change regardless.  I've kicked of a gnuradio
> rebuild here:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=39436995
>
> > Also the perl-thrift sub-package of thrift seems to be broken and
> > isn't even installable with the new version:
> >
> > Error:
> >   Problem: conflicting requests
> >- nothing provides perl(Thrift::Exception) needed by
> > perl-thrift-0.13.0-1.fc32.noarch
> >- nothing provides perl(Thrift::MessageType) needed by
> > perl-thrift-0.13.0-1.fc32.noarch
> >- nothing provides perl(Thrift::Type) needed by
> > perl-thrift-0.13.0-1.fc32.noarch
>
> Interesting.  Thrift appears to have pretty broken perl packaging as
> well (classes inside of files with a different name).  I've added a hack
> for that in thrift-0.13.0-2 which should resolve that.
>
> >
> > Fabio
>
> Thanks again.

Hi Orion,

Thanks for fixing the issues so quickly! I also hope my original
message didn't come across as too negative / critical. I just wanted
to give devel@ a short heads-up that something was broken in rawhide,
so it can be fixed in a timely manner, as well :)

Fabio

> --
> Orion Poplawski
> Manager of NWRA Technical Systems  720-772-5637
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> Boulder, CO 80301 https://www.nwra.com/
>
___
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: Bohdi / Create New Update - I miss the field Builds

[Martin Gansser]

I mean this field [1]

[1] https://martinkg.fedorapeople.org/ErrorReports/bohdi/bohdi.png
___
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: (thinking about) unretiring xmlbeans

[Fabio Valentini]

On Thu, Dec 5, 2019 at 1:52 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> xmlbeans [1,2] got retired because of lack of maitainers.
> It's used by diffoscope now, so I'm thinking about adopting it.
> Any major reasons not to? Fedora was at 2.6.0, upstream is now at
> 3.1.0, so it'd be definitely some effort to update...

Hi Zbigniew,

It looks like all its dependencies are still in rawhide, so I see no
reason not to revive it, especially if its still useful.
You'll need a re-review of the package though, since it's been retired
for more than 8 weeks.

I suggest you also unorphan one of its dependencies (saxon) before it
gets retired.
https://src.fedoraproject.org/rpms/saxon

Fabio

> [1] https://xmlbeans.apache.org/
> [2] https://src.fedoraproject.org/rpms/xmlbeans
>
> Zbyszek
> ___
> 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
___
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

Self Introduction: Philip Matura

[pfed]

Hello,

my name is Philip Matura and I'm currently a student in mathematics. In
my freetime I'm doing audio/music and electronics stuff. I've been
converted to the Linux world with Fedora about 10 years ago and would
like to give some things back.

So there are currently four packages I would like to see included in
Fedora eventually, to which I would lend a hand in order to make that
happen. Three of them already were submitted in the past, but didn't
make it through (yet):

aelous (https://bugzilla.redhat.com/show_bug.cgi?id=789390)
drumgizmo (https://bugzilla.redhat.com/show_bug.cgi?id=1210356)
helm (https://bugzilla.redhat.com/show_bug.cgi?id=1661657)

But for now I'll start with this one:

zita-njbridge (https://bugzilla.redhat.com/show_bug.cgi?id=1780297)

So I am looking for a sponsor.

Greetings,
Philip

GPG: 44300632B5E49E6A81528B9EE0538557D42A4B04


pgpI2Pj3THMUv.pgp
Description: PGP signature
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Przemek Klosowski via devel]

On 12/4/19 6:59 PM, John M. Harris Jr wrote:

On Wednesday, December 4, 2019 12:38:20 PM MST Przemek Klosowski via devel
wrote:

- stolen/lost laptop:  I think this is the most important one for most
people; it is mitigaged by a trusted-network-based decryption, unless
the device is in unencrypted sleep mode and the new 'beneficial owner'
manages to read the disk before the system goes down.

That may be the case for home users, but not for businesses. Let's take this
example. Employee A has files from a given project, but Employee B doesn't
have access to that project. Employee B is malicious, and takes Employee A's
laptop, gets it on the network, it unencrypts itself and then takes it.
Defending against threat model allowing physical access and malicious 
insiders, who e.g. install a screen/keyboard capturing camera in the 
target office, is an entirely different ballgame, requiring multi-factor 
authentication, etc. --- and even those are not infallible (c.f. wikileaks).



- someone breaks into your home/office/hotel room and extracts the data:
important to some people but not very common scenario.

This is important to most businesses.
Same argument as above. Again, we're talking about taking care of the 
low hanging fruit like hard disks stripped from equipment and sold on Ebay.
___
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: Bohdi / Create New Update - I miss the field Builds

[Pierre-Yves Chibon]

On Thu, Dec 05, 2019 at 03:12:50PM -, Martin Gansser wrote:
> Hi,
> 
> i want to create a new update on bohdi for the package 
> vdr-epg2vdr-1.1.103-2.fc31, but i miss the field Builds on create new update.
> What is going wrong ?

First field at the top?

Or maybe you could share a screenshot via: https://img.susepaste.org/ ?

Pierre
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Marius Schwarz]

Am 05.12.19 um 13:32 schrieb Lennart Poettering:
> Well, the way this has been traditionally done is that the lock screen
> is displayed by a program running under the user's identity and that
> the user's data is entirely unlocked the entire time during suspend,
That depends on what you have chosen "sleep" or "hibernate" .

If the device just sleeps, your data is unprotected, as the key could be
in your still powered memory bank.

With hibernation, as far as I have seen it with my devices, the hw stops
entirely after saving the memory state to disk,
an encrypted disk I may add. On boot, it asks for the decryption keys as
it would normally do, finds the hibernate signature
on swap ( i presume / which is also encrypted ) and restores memory. I
don't see a way for an attack here.

I think your approach is not to the full extent of all possible user
data locations. Some examples:

/var/lib/mysql  MariaDB SQL Database ( required i.e. by MythTV )
/var/www/   Apache Webserver ( required i.e. by RoundCube, BackupPC
or Gnome User-Share )

if those aren't common enough, this will be:

/media/    Additional Storage Drives

It's quite common to have additional storage space on a desktop pc,
which do not exactly extend /home/ space, more general space. If you
have more than one "user" on a system, you can't mount it into
/home/username/path as of the rights management.

When I had to estimate my system, it's a hundred GB in /home/ against a
few TB != /home . Anyone who as ever bought a second drive for
his/her/it pc , will face this problem, or has to learn to use LVM.  I
don't think it will work for the majority of userbase. It will only work
for simple cases.

best regards,
Marius



___
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: Firefox crashes at Rawhide

[Jan Pokorný]

On 03/12/19 13:29 +0100, Martin Stransky wrote:
> Just FYI, Firefox is recently crashing on Rawhide due to two independent
> issues as rawhide gets all builds automatically:
> 
> 1) PGO mis-compilation/Firefox bug
> (https://bugzilla.redhat.com/show_bug.cgi?id=1779082). Please use 'npgo'
> builds from koji.
> 
> 2) glibc update (https://bugzilla.mozilla.org/show_bug.cgi?id=1600574#c8)
> You can disable e10s as a workaround (set MOZ_FORCE_DISABLE_E10S=1 or
> browser.tabs.remote.autostart at about:config)

Thanks for the heads-up, for me, I seem to have been forced to
downgrade down to glibc-2.30.9000-20.fc32 so as to fix 2) reliably
("env MOZ_FORCE_DISABLE_E10S=1 firefox" made the actual content
to render, but led to a crash upon tab being closed or so).

-- 
Jan (Poki)


pgpQj96EOOAwx.pgp
Description: PGP signature
___
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

Bohdi / Create New Update - I miss the field Builds

[Martin Gansser]

Hi,

i want to create a new update on bohdi for the package 
vdr-epg2vdr-1.1.103-2.fc31, but i miss the field Builds on create new update.
What is going wrong ?

Regards
Martin
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Lennart Poettering]

On Do, 05.12.19 15:23, Kevin Kofler (kevin.kof...@chello.at) wrote:

> Lennart Poettering wrote:
> > Uh, first of all plain full disk encryption like we set it up
> > typically on Fedora provides confidentiality, not integrity.
>
> Well, it does protect against offline modification (i.e., "borrow" the
> computer or the storage devices, put the storage devices into another
> computer, trojan the OS, and return the "borrowed" device without getting
> caught; or even just boot the computer from a malicious boot device and
> trojan the OS from there, if the boot order is not locked). It does not
> protect against online modification (i.e., attack the system while it is
> running and the disk is decrypted).

No it does not protect against offline modification. That's why
dm-integrity exists after all.

If you use LUKS/dm-crypt without dm-integrity and you have a clue
where things are located then you can change files without anything
being able to detect that. (On btrfs you might have some luck, since
it has data checksumming, but ext4 and other traditional file systems
do not).

And it's easier to figure out where stuff is located then you might
think since we live in a world where people use SSDs and mount file
systems with "discard", so that what are used blocks and what are free
blocks is propagated to the underlying device. Moreover file systems
write in certain patterns, i.e. try to keep large files in one stream
together, put files in the same directories adjacent to each other and
so on, and are usually roughly reproducible.

Lennart

--
Lennart Poettering, Berlin
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Kevin Kofler]

Nico Kadel-Garcia wrote:
> Let's not go too far down the "gummy fingerprint" thread. If a
> sophisticated person has your laptop, they probably have your
> fingerprints, and very few fingerprint scanners successfully resist a
> duplicated and printed fingerprint.

We were talking about SSH key fingerprints here, not actual (biometric) 
finger prints.

Kevin Kofler
___
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: Should we discontinue the Python Classroom Lab?

[John M. Harris Jr]

On Thursday, December 5, 2019 3:44:50 AM MST Miro Hrončok wrote:
>   - Docker is broken
> - one of the main ideas was to produce a Docker image
> - the Docker instructions on the download page [4] are not working
> - not even when replaced with podman
> - I have no idea how to fix it
> - I know no way to upload to official dockerhub [5]

What's wrong with the packaged version of Docker?

-- 
John M. Harris, Jr.
Splentity

___
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: Should we discontinue the Python Classroom Lab?

[Ben Cotton]

On Thu, Dec 5, 2019 at 5:46 AM Miro Hrončok  wrote:
>
> I'd like to know whether it makes sense to continue maintaining and producing
> the Fedora Python Classroom Lab.
>
I can't answer that question for you, but I can address a few of the below:

>   - no issue tracker, I don't even know if there are users with issues
> - there has simple been close to zero feedback, maybe nobody uses this?
>
Maybe? I recently created a component in Bugzilla for IoT. I can do
that for Classroom Lab, too. I've been talking with mattdm about doing
that for all of our editions, spins, and labs, we just haven't decided
on the approach yet.

>   - the website is horribly outdated: 
> https://pagure.io/fedora-websites/issue/962
>
In the absence of a thriving website team, I've blocked out a few
hours next week to take care of some of the easier web tasks, so this
should be fixed soon.

>   - some Fedora versions weren't built:
> - I wasn't notified when F29 wasn't built
> - there was no way to get it fixed ex-post
> - https://pagure.io/releng/issue/7922
>
No good answers here, but I think everyone agrees this is something we
want to have fixed.

>   - Docker is broken
> - one of the main ideas was to produce a Docker image
> - the Docker instructions on the download page [4] are not working
> - not even when replaced with podman
> - I have no idea how to fix it
> - I know no way to upload to official dockerhub [5]
>
>   - Vagrant experience is not good enough
> - one of the main ideas was to produce a Vagrant box/image
> - I know no way to upload to official Vagrant thing [6]
> - downloading the box manually is tedious
>
I can't help here either, but if there's something I can do to help
you make connections or find the resources, please let me know.

> The absolute lack of feedback makes is hard to dedicate time to actually
> persuade and fix the problems.
>
I understand that. The Python Classroom Lab is a great example of what
we'd like to enable people to do in Fedora, but if you don't have the
motivation or there's no user base, I'm sure you have a long list of
other things you'd like to work on. :-)

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Kevin Kofler]

Lennart Poettering wrote:
> Uh, first of all plain full disk encryption like we set it up
> typically on Fedora provides confidentiality, not integrity.

Well, it does protect against offline modification (i.e., "borrow" the 
computer or the storage devices, put the storage devices into another 
computer, trojan the OS, and return the "borrowed" device without getting 
caught; or even just boot the computer from a malicious boot device and 
trojan the OS from there, if the boot order is not locked). It does not 
protect against online modification (i.e., attack the system while it is 
running and the disk is decrypted).

Kevin Kofler
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[John M. Harris Jr]

On Thursday, December 5, 2019 7:07:04 AM MST Neal Gompa wrote:
> Please don't suggest that password-based auth for SSH is insecure.
> That's not even close to true. A password isn't terribly different
> from an SSH key from an authentication perspective. If the password is
> strong or hard to crack, then it's fine.

It's not insecure as a mechanism, but, without something like fail2ban, it 
takes a surprisingly short amount of time to break into systems using password 
authentication. In practice, it is insecure, especially when compared to the 
other options.

> Frankly, it's irresponsible to give blanket statements like that,
> because they're untrue and do not recognize the nuance of threat
> models and risk assessments.

It is irresponsible to suggest password based authentication, especially at a 
time where residential ranges especially are being mass scanned, and bots 
attempt to break into these systems once ssh servers with password 
authentication have been found.

> For the vast majority of people using SSH in a non-shared context
> (i.e. not a VPS or some kind of easily accessible server), password
> auth is more than sufficient with a strong enough password or
> passphrase.

This would depend heavily on what environment they're using it on. If it never 
connects to the internet, you would be correct. If it connects to shared wifi, 
or home wifi with the average home router, then I would argue that it is not 
sufficient to use password authentication. Especially on shared wifi, for 
example guest wifi at most businesses.

-- 
John M. Harris, Jr.
Splentity

___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Neal Gompa]

On Thu, Dec 5, 2019 at 9:02 AM John M. Harris Jr  wrote:
>
> On Thursday, December 5, 2019 5:41:44 AM MST Nico Kadel-Garcia wrote:
> > If someone wants to spend that much of their resources on homedir
> > security, they need to decide whether they want SSH key based access.
> > That is manageable by configuring SSH to store SSH public keys in an
> > alternate location and inform the users of the modified sshd_config
> > and its modified, accessible "AuthorizedKeysFile" setting. Or the user
> > can spend the time and effort to activate Kerberos based logins, or
> > use password based logins. I'd avoid trying to rewrite SSH for such an
> > OS-specific and non-portable need as homedir decryption mounting.
>
> Please don't recommend to anyone to use passwords for SSH. That is incredibly
> insecure, and if privileged users are using password-based SSH, that'll
> quickly lead to a serious compromise of your entire system, depending on the
> complexity of the password, of course, but still holds nothing to key-based
> authentication with the best password.
>

Please don't suggest that password-based auth for SSH is insecure.
That's not even close to true. A password isn't terribly different
from an SSH key from an authentication perspective. If the password is
strong or hard to crack, then it's fine.

Frankly, it's irresponsible to give blanket statements like that,
because they're untrue and do not recognize the nuance of threat
models and risk assessments.

For the vast majority of people using SSH in a non-shared context
(i.e. not a VPS or some kind of easily accessible server), password
auth is more than sufficient with a strong enough password or
passphrase.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[John M. Harris Jr]

On Thursday, December 5, 2019 5:07:04 AM MST Marius Schwarz wrote:
> Hi,
> 
> Am 25.11.19 um 22:59 schrieb Samuel Sieb:
> 
> >
> >
> > Steps 1 - 4 are not benefits, they are workarounds to critical system
> > utilities required by this change.  I don't understand why this change
> > is necessary at all.  It only affects local logins and if someone
> > wants to have an empty password, why make it so difficult?  It's their
> > choice.  It's not like Fedora has any default logins with empty
> > passwords, the user has to make their own.
> 
> 
> I know at least two real exiting none nerd users, who will agree with
> you, as they use FullDiskEnc and no further passwords to Login after boot.
> 
> Which would be impossible if the changes will be made. I personally have
> only on scenario to offer:
> 
> A tablet pc is booted directly into the desktop, as any other tablet
> (android or ipad) will do.
> 
> @Ben.Cotton
> 
> Will that be still possible, when empty passwords are dismissed?

Only if this configuration is modified by the end-user while setting up that 
kiosk-like systems.

-- 
John M. Harris, Jr.
Splentity

___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[John M. Harris Jr]

On Thursday, December 5, 2019 5:53:18 AM MST Nico Kadel-Garcia wrote:
> On Wed, Dec 4, 2019 at 9:24 PM John M. Harris Jr 
> wrote:
> >
> >
> > On Wednesday, December 4, 2019 6:02:07 PM MST Kevin Kofler wrote:
> > 
> > > John M. Harris Jr wrote:
> > >
> > >
> > >
> > > > Well, you could theoretically use ssh-agent (or equivalent), without
> > > > changing the protocol in any way.
> > >
> > >
> > >
> > >
> > > You need protocol support to do this securely. Otherwise, your ssh-agent
> > > is
> > 
> > >  a decryption oracle which can be used by an attacker to decrypt your
> > >  LUKS
> > > 
> > > keyfile on demand. The decryption should only be possible as part of
> > > the
> > > login process after the server fingerprint has been verified and before
> > > arbitrary application data can be sent.
> >
> >
> >
> > Oh, of course after fingerprint verification. Luckily, that can be
> > accomplished by forcing a fake shell which would run a check to see if
> > the
> > home directory is already mounted. If it's not, it'd use the ssh agent,
> > or
> > equivalent, then execute the real shell. If it's already mounted, short
> > circuit to the last step, executing the real shell.
> 
> 
> Let's not go too far down the "gummy fingerprint" thread. If a
> sophisticated person has your laptop, they probably have your
> fingerprints, and very few fingerprint scanners successfully resist a
> duplicated and printed fingerprint.

We were talking about ssh key fingerprints. I would never suggest fingerprint 
scanners as a form of security.

-- 
John M. Harris, Jr.
Splentity

___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[John M. Harris Jr]

On Thursday, December 5, 2019 5:35:09 AM MST Lennart Poettering wrote:
> On Do, 05.12.19 04:30, John M. Harris Jr (joh...@splentity.com) wrote:
> > Well, you are, in that the average attacker have to break or steal a key
> > to decrypt the drive first. Sure, it wouldn't stop a sophisticated
> > attack.
> 
> 
> Not how this works.

It is. If you cannot decrypt it, you cannot modify it, nor even read it.

> > This is not generally true either. Encrypting /boot helps to ensure that
> > /boot is not modified, and is generally paired with GRUB signature
> > validation. In some setups, this GRUB configuration is moved to flash
> > storage.
> 
> 
> You are conflating integrity and confidentiality. If you want to
> protect boot loaders against modification you want the former, not
> necessarily the latter.

I am not conflating the two, though confidentiality inherently provides a 
certain degree of integrity. If you want to protect boot loaders against 
modification, you want *both*.

-- 
John M. Harris, Jr.
Splentity

___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[John M. Harris Jr]

On Thursday, December 5, 2019 5:41:44 AM MST Nico Kadel-Garcia wrote:
> If someone wants to spend that much of their resources on homedir
> security, they need to decide whether they want SSH key based access.
> That is manageable by configuring SSH to store SSH public keys in an
> alternate location and inform the users of the modified sshd_config
> and its modified, accessible "AuthorizedKeysFile" setting. Or the user
> can spend the time and effort to activate Kerberos based logins, or
> use password based logins. I'd avoid trying to rewrite SSH for such an
> OS-specific and non-portable need as homedir decryption mounting.

Please don't recommend to anyone to use passwords for SSH. That is incredibly 
insecure, and if privileged users are using password-based SSH, that'll 
quickly lead to a serious compromise of your entire system, depending on the 
complexity of the password, of course, but still holds nothing to key-based 
authentication with the best password.

> In common usage, very few people encrypt their home directories
> separately from their basic disk image. It makes system management for
> administrators or even a local root user very awkward. I could see it
> for home directories in "/home", and it would only cost SSH key based
> access, not ordinary password or Kerberos ticket based login. But it
> sounds quite risky and destabilizing, much as the "kill dangling
> processes when people log out". That  caused a lot of shock when it
> was activated by default and started killing processes with no
> logging. Let's not repeat a surprise like that and avoid killing SSH
> key access by default.

A bit off topic, but where is "kill danging processes when people log out" 
set? I've not experienced that anywhere.

-- 
John M. Harris, Jr.
Splentity

___
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: Self Introduction: Theo Papadopoulo

[Theodore Papadopoulo]

On 12/5/19 2:50 PM, Theodore Papadopoulo wrote:
>   Hello,
> 
> My name is Theo Papadopoulo. I use linux based systems since 1996 and
> redhat/fedora ones since so long I do not quite remember (2005-2007?).
> Fedora is used within the research group (and actually with the research
> institute where I am) I belong to as the main computing platform. I'm
> participating in some specialized open source project you may not even
> know (OpenMEEG, OpenViBE or medInria) and occasionally helped in some
> more widespread - to somne extent - ones (blitz, matio, xtensor). I even
> have a very minor contribution to gcc years ago
> 
> Given this context, I often maintain a set of rpms for the group I
> belong. Very often those are packages that we need internally. But
> sometimes, this is just to cope with some orphaned fedora packages I'd
> like to give back to the community if possible
> 
>   All the best,
> 

And to reply to myself, here are (just the specs) of two packages I'd
like to un-retire. The first one is liblsl which is updated just a few
days ago and which was orpaned very recently). The second one itpp was
orphaned quite some time ago, and maybe about 1 year ago I had some
review on a new itpp spec file that probably needs to be updated now.

Those are the two packages I'd like to see back in fedora. I'd prefer to
co-maintain them if possible (for itpp I suspect they is no longer a
packager, for liblsl the packager seems to have been unresponsive to all
messages prior to the retiring of the package). If not, if someone could
sponsor me, I will try to do my best to regularly update those two
which should not belong to any critical path as they are retired (so I
guess there is little risk for me to harm the whole distribution).

Regards,

Theo.

%global version_major 1
%global version_minor 13
%global version_patch 0
%global version_release b13

Name:		liblsl
Version:	%{version_major}.%{version_minor}.%{version_patch}.%{version_release}
Release:	1%{?dist}
Summary:	Lab streaming layer API

License:	MIT
URL:		https://github.com/sccn/labstreaminglayer

# Source archived from git repo, excluding external libraries like boost:
# git clone https://github.com/sccn/labstreaminglayer.git
# cd labstreaminglayer/LSL/liblsl
# git archive --prefix=%%{name}-%%{version}/ %%{version} . | xz > %%{SOURCE0}
Source0:	%{name}-%{version}.tar.xz
Patch0:		liblsl-1.13.0-use_system_pugixml.patch
Patch1:		liblsl-1.13.0-install.patch

BuildRequires:  gcc-c++
BuildRequires:	boost-devel
BuildRequires:	cmake
BuildRequires:	dos2unix
BuildRequires:	pugixml-devel

Provides:	bundled(boost-endian)
Provides:	bundled(portable-archive)

%description
The lab streaming layer is a simple all-in-one approach to streaming experiment
data between applications in a lab, e.g. instrument time series, event markers,
audio, and so on.


%package devel
Summary:	Lab streaming layer API development files
Requires:	%{name}%{?_isa} = %{version}-%{release}

%description devel
Development files for liblsl.


%prep
%autosetup -p1
dos2unix CHANGELOG README.md LICENSE
find examples -type f \( -name '*.c' -o -name '*.cpp' \) -exec \
dos2unix {} \;
find examples -type f \( -name '*.c' -o -name '*.cpp' \) -exec \
sed -i '/^#include/s|\.\./\.\./\.\./include/||' {} \;
find examples -type f -name '*.vcproj' -delete
find examples -type f -name '*.vcxproj' -delete
find examples -type d -name '*.xcodeproj' -exec rm -rf {} +


%build
mkdir build
pushd build
%cmake \
-DLSL_NO_FANCY_LIBNAME=ON\
-DUSE_SYSTEM_BOOST=ON \
..
%make_build
popd


%install
pushd build
%make_install
popd


%ldconfig_scriptlets


%files
%license LICENSE src/portable_archive/license.txt
%doc CHANGELOG README.md
%{_libdir}/*.so.*
%{_bindir}/*

%files devel
%doc examples
%{_includedir}/%{name}
%{_libdir}/*.so
%{_datadir}/*


%changelog
* Tue Dec 3 2019 Theodore Papadopoulo  - 1.13.0.b13-1
- New upstream release (tag 1.13.0-b13)

* Thu Jul 25 2019 Fedora Release Engineering  - 1.12.0-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild

* Fri Feb 01 2019 Fedora Release Engineering  - 1.12.0-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild

* Fri Jul 13 2018 Fedora Release Engineering  - 1.12.0-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild

* Thu Jun 14 2018 Dmitry Mikhirev  - 1.12.0-3
- Fix build with boost 1.66+ (#1556596)

* Wed Feb 07 2018 Fedora Release Engineering  - 1.12.0-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild

* Sun Nov 26 2017 Dmitry Mikhirev  - 1.12.0-1
- New upstream release (#1504351)
- Convert line endings in examples to unix format

* Thu Aug 03 2017 Fedora Release Engineering  - 1.11.0-10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild

* Wed Jul 26 2017 Fedora Release Engineering  - 1.11.0-9
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild

* Wed Jul 19 2017 Jonathan Wakely  - 1.11.0-8
- Rebuilt for 

Re: Self Introduction: Theo Papadopoulo

[alciregi]

On Thu, 2019-12-05 at 14:50 +0100, Theodore Papadopoulo wrote:
> participating in some specialized open source project you may not
> even
> know (OpenMEEG, OpenViBE or medInria) and occasionally helped in some

Hello Theo! Welcome.
Look here :-) https://pagure.io/neuro-sig/NeuroFedora/issue/279

You could consider to get in touch with the Neuro SIG: 
https://docs.fedoraproject.org/en-US/neurofedora/overview/


Ciao,
A.
___
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

Self Introduction: Theo Papadopoulo

[Theodore Papadopoulo]

Hello,

My name is Theo Papadopoulo. I use linux based systems since 1996 and
redhat/fedora ones since so long I do not quite remember (2005-2007?).
Fedora is used within the research group (and actually with the research
institute where I am) I belong to as the main computing platform. I'm
participating in some specialized open source project you may not even
know (OpenMEEG, OpenViBE or medInria) and occasionally helped in some
more widespread - to somne extent - ones (blitz, matio, xtensor). I even
have a very minor contribution to gcc years ago

Given this context, I often maintain a set of rpms for the group I
belong. Very often those are packages that we need internally. But
sometimes, this is just to cope with some orphaned fedora packages I'd
like to give back to the community if possible

All the best,

Theo.


0x12BF16AD4F273D5D.asc
Description: application/pgp-keys
___
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

Fedora rawhide compose report: 20191205.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20191204.n.0
NEW: Fedora-Rawhide-20191205.n.0

= SUMMARY =
Added images:6
Dropped images:  1
Added packages:  4
Dropped packages:1
Upgraded packages:   152
Downgraded packages: 0

Size of added packages:  126.17 MiB
Size of dropped packages:92.67 KiB
Size of upgraded packages:   4.35 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   32.37 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Cloud_Base vmdk s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20191205.n.0.s390x.vmdk
Image: Everything boot s390x
Path: 
Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20191205.n.0.iso
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20191205.n.0.s390x.raw.xz
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20191205.n.0.s390x.tar.xz
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20191205.n.0.s390x.qcow2
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20191205.n.0.s390x.tar.xz

= DROPPED IMAGES =
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20191204.n.0.iso

= ADDED PACKAGES =
Package: bcftools-1.9-1.fc32
Summary: Tools for genomic variant calling and manipulating VCF/BCF files
RPMs:bcftools
Size:2.49 MiB

Package: retroarch-1.8.1-14.fc32
Summary: Cross-platform, sophisticated frontend for the libretro API.
RPMs:retroarch retroarch-assets retroarch-filters
Size:114.18 MiB

Package: rubygem-linked-list-0.0.13-1.fc32
Summary: Ruby implementation of Doubly Linked List, following some Ruby idioms
RPMs:rubygem-linked-list rubygem-linked-list-doc
Size:234.27 KiB

Package: virt-v2v-1.41.8-4.fc32
Summary: Convert a virtual machine to run on KVM
RPMs:virt-v2v virt-v2v-bash-completion virt-v2v-man-pages-ja 
virt-v2v-man-pages-uk
Size:9.28 MiB


= DROPPED PACKAGES =
Package: x-tile-2.6-1.fc31
Summary: A GTK application to tile windows in different ways
RPMs:x-tile
Size:92.67 KiB


= UPGRADED PACKAGES =
Package:  Lmod-8.2.9-1.fc32
Old package:  Lmod-8.2.8-1.fc32
Summary:  Environmental Modules System in Lua
RPMs: Lmod
Size: 1.03 MiB
Size change:  1.05 KiB
Changelog:
  * Thu Dec 05 2019 Orion Poplawski  - 8.2.9-1
  - Update to 8.2.9


Package:  OpenImageIO-2.0.13-1.fc32
Old package:  OpenImageIO-2.0.12-1.fc32
Summary:  Library for reading and writing images
RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils 
python3-openimageio
Size: 34.19 MiB
Size change:  22.48 KiB
Changelog:
  * Wed Dec 04 2019 Richard Shaw  - 2.0.13-1
  - Update to 2.0.13.


Package:  R-rversions-2.0.1-1.fc32
Old package:  R-rversions-2.0.0-3.fc31
Summary:  Query 'R' Versions, Including 'r-release' and 'r-oldrel'
RPMs: R-rversions
Size: 76.78 KiB
Size change:  29.97 KiB
Changelog:
  * Tue Dec 03 2019 Elliott Sales de Andrade  - 
2.0.1-1
  - Update to latest version


Package:  alsa-lib-1.2.1.2-3.fc32
Old package:  alsa-lib-1.2.1.2-1.fc32
Summary:  The Advanced Linux Sound Architecture (ALSA) library
RPMs: alsa-lib alsa-lib-devel alsa-topology alsa-ucm
Size: 7.17 MiB
Size change:  10.53 KiB
Changelog:
  * Tue Dec 03 2019 Jaroslav Kysela  - 1.2.1.2-3
  - Fixed more UCM2 related issues


Package:  ansible-review-0.13.9-1.fc32
Old package:  ansible-review-0.13.7-7.fc32
Summary:  Reviews Ansible playbooks, roles and inventory and suggests 
improvements
RPMs: python3-ansible-review
Size: 53.95 KiB
Size change:  664 B
Changelog:
  * Wed Dec 04 2019 Nils Philippsen  - 0.13.9-1
  - upstream bugfix release 0.13.9:
https://github.com/willthames/ansible-review/blob/master/CHANGELOG.md#0139
  - get rid of Python 2 support in the spec file
  - sort deps


Package:  arm-trusted-firmware-2.2-3.fc32
Old package:  arm-trusted-firmware-2.2-2.fc32
Summary:  ARM Trusted Firmware
RPMs: arm-trusted-firmware-armv8
Size: 143.58 KiB
Size change:  7.70 KiB
Changelog:
  * Wed Dec 04 2019 Peter Robinson  2.2-3
  - Minor build fixes and cleanup


Package:  arptables-0.0.5-1.fc32
Old package:  arptables-0.0.4-20.fc32
Summary:  User space tool to set up tables of ARP rules in kernel
RPMs: arptables-legacy arptables-services
Size: 325.58 KiB
Size change:  523 B
Changelog:
  * Wed Dec 04 2019 Phil Sutter  - 0.0.5-1
  - New version 0.0.5


Package:  autodownloader-0.4.0-2.fc32
Old package:  autodownloader-0.4.0-1.fc32
Summary:  GUI-tool to automate the download of certain files
RPMs: autodownloader
Size: 38.38 KiB
Size change:  95 B
Changelog:
  * Wed Dec 04 2019 Pete Walter  - 0.4.0-2
  - Avoid hardcoding /usr prefix


Package:  bcc-0.11.0-2.fc32
Old

[Bug 1763313] perfl-utf8-all not available in EPEL8

[bugzilla]

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



--- Comment #4 from Petr Pisar  ---
You need to enable CodeReady Build / PowerTools repository
.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

[Nico Kadel-Garcia]

On Wed, Dec 4, 2019 at 9:24 PM John M. Harris Jr  wrote:
>
> On Wednesday, December 4, 2019 6:02:07 PM MST Kevin Kofler wrote:
> > John M. Harris Jr wrote:
> >
> > > Well, you could theoretically use ssh-agent (or equivalent), without
> > > changing the protocol in any way.
> >
> >
> > You need protocol support to do this securely. Otherwise, your ssh-agent is
> >  a decryption oracle which can be used by an attacker to decrypt your LUKS
> > keyfile on demand. The decryption should only be possible as part of the
> > login process after the server fingerprint has been verified and before
> > arbitrary application data can be sent.
>
> Oh, of course after fingerprint verification. Luckily, that can be
> accomplished by forcing a fake shell which would run a check to see if the
> home directory is already mounted. If it's not, it'd use the ssh agent, or
> equivalent, then execute the real shell. If it's already mounted, short
> circuit to the last step, executing the real shell.

Let's not go too far down the "gummy fingerprint" thread. If a
sophisticated person has your laptop, they probably have your
fingerprints, and very few fingerprint scanners successfully resist a
duplicated and printed fingerprint.
___
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

(thinking about) unretiring xmlbeans

[Zbigniew Jędrzejewski-Szmek]

xmlbeans [1,2] got retired because of lack of maitainers.
It's used by diffoscope now, so I'm thinking about adopting it.
Any major reasons not to? Fedora was at 2.6.0, upstream is now at
3.1.0, so it'd be definitely some effort to update...

[1] https://xmlbeans.apache.org/
[2] https://src.fedoraproject.org/rpms/xmlbeans

Zbyszek
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Nico Kadel-Garcia]

On Wed, Dec 4, 2019 at 6:01 AM Lennart Poettering  wrote:

> (One thinkable extension of homed's current model btw is to support
> logind lingering by asking for the user pw using plymouth. this would
> then mean you'd be asked to unlock your user during early boot like as
> with classic disk encryption, and then it remains unlocked for the
> entire lifetime of the system. But I am not sure it's worth it, if you
> are happy with such a much weaker model you might as well use regular
> full disk encryption and have the home dirs themselves just be plain
> directories)
>
> Lennart

If someone wants to spend that much of their resources on homedir
security, they need to decide whether they want SSH key based access.
That is manageable by configuring SSH to store SSH public keys in an
alternate location and inform the users of the modified sshd_config
and its modified, accessible "AuthorizedKeysFile" setting. Or the user
can spend the time and effort to activate Kerberos based logins, or
use password based logins. I'd avoid trying to rewrite SSH for such an
OS-specific and non-portable need as homedir decryption mounting.

In common usage, very few people encrypt their home directories
separately from their basic disk image. It makes system management for
administrators or even a local root user very awkward. I could see it
for home directories in "/home", and it would only cost SSH key based
access, not ordinary password or Kerberos ticket based login. But it
sounds quite risky and destabilizing, much as the "kill dangling
processes when people log out". That  caused a lot of shock when it
was activated by default and started killing processes with no
logging. Let's not repeat a surprise like that and avoid killing SSH
key access by default.
___
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

OCaml 4.09.0 will be added to Fedora 32 via a side tag

[Richard W.M. Jones]

Builds will start soon into a side tag (f32-build-side-14856), and
then if everything goes OK I will merge it into Rawhide.

This version should have fixed RISC-V support which is broken
currently (and requires some extremely difficult to backport fixes -
we already tried that and gave up, so upgrading to OCaml 4.09 is the
only solution if you want fixed RISC-V support).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Lennart Poettering]

On Do, 05.12.19 04:30, John M. Harris Jr (joh...@splentity.com) wrote:

> > Unless you combine dm-crypt with dm-integrity (which we currently
> > generally do not do), or you use dm-verity you are not actually
> > protecting the OS from undetected modification.
>
> Well, you are, in that the average attacker have to break or steal a key to
> decrypt the drive first. Sure, it wouldn't stop a sophisticated
> attack.

Not how this works.

> > And there's no point in encrypting /boot, because that contains only
> > public information too. If you want to protect your boot chain, use
> > something like a complete SecureBoot chain, but that too is something
> > we currently don't actually support on Fedora. (because initrds are
> > not verified).
>
> This is not generally true either. Encrypting /boot helps to ensure that /boot
> is not modified, and is generally paired with GRUB signature validation. In
> some setups, this GRUB configuration is moved to flash storage.

You are conflating integrity and confidentiality. If you want to
protect boot loaders against modification you want the former, not
necessarily the latter.

Lennart

--
Lennart Poettering, Berlin
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Lennart Poettering]

On Do, 05.12.19 12:02, Marius Schwarz (fedora...@cloud-foo.de) wrote:

> With FDE running and "Suspend-to-disk" selected in your screensafer
> settings, you get asked for your password on hw wakeup before your
> system gets back running. If someone wants to use such things, he
> already can.

Well, the way this has been traditionally done is that the lock screen
is displayed by a program running under the user's identity and that
the user's data is entirely unlocked the entire time during suspend,
i.e. the decryption key is lying around in memory just fine. If you
steal a laptop that way and read out the memory (which sufficiently
sophisticated hackers can, via thunderbolt DMA for example, or finding
an exploit in the screen locker, like we prominently had in the past
in xscreensaver) then you have full acces to your full data. The
intention here is to lock things down so that while the system is
suspended you can rest safely that it is as locked down as it would be
if the device was turned off. i.e. so that if you manage to exploit
xscreensaver or if you manage to exploit thunderbolt, or manage to
exploit the kernel it doesn't help you anything, because the crypto
keys are not present on the device anymore.

> Where is the advantage of homed, considering, that only encrypting
> /home, is a major security flaw by itself. All your goals are
> already there and it's more useful and secure too :) I really have a
> problem understanding why you wanne implement a security flaw and
> call it "better".

Locking down the OS itself and locking down the user's home are two
different things, because OS integrity should be bound to different
mechanisms than user data encryption. (i.e. OS integrity should be
bound to vendor trust or TPM, while user data should be bound to
user's security credentials).

> If you wanne improve security, please focus on userfriendlyneess for
> things like "disabling unused usb ports"/"whitelist for usb
> ids"/"insecure Highspeed USB network adapter detection"  same for any
> plugable port you have in your hw. And last, but not least, "motherboard
> serial number validation on wakeup" to counter the switch of hw components.

Uh, locking down USB like that doesn't really work. USB has no
mechanism for recognizing devices securely, which means any whitelist
is pointless because any device can claim to be whatever it wants to
be. (And yes, it would be great if we could be a bit more secure
there, but it's an orthogonal problem)

Lennart

--
Lennart Poettering, Berlin
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Marius Schwarz]

Hi,

Am 25.11.19 um 22:59 schrieb Samuel Sieb:
>
> Steps 1 - 4 are not benefits, they are workarounds to critical system
> utilities required by this change.  I don't understand why this change
> is necessary at all.  It only affects local logins and if someone
> wants to have an empty password, why make it so difficult?  It's their
> choice.  It's not like Fedora has any default logins with empty
> passwords, the user has to make their own.

I know at least two real exiting none nerd users, who will agree with
you, as they use FullDiskEnc and no further passwords to Login after boot.

Which would be impossible if the changes will be made. I personally have
only on scenario to offer:

A tablet pc is booted directly into the desktop, as any other tablet
(android or ipad) will do.

@Ben.Cotton

Will that be still possible, when empty passwords are dismissed?

best regards,
Marius

___
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

[Bug 1763313] perfl-utf8-all not available in EPEL8

[bugzilla]

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

Trunet  changed:

   What|Removed |Added

 CC||trunet-red...@wsartori.com



--- Comment #3 from Trunet  ---
I'm still having problems:

# yum install perl-utf8-all
Last metadata expiration check: 0:00:15 ago on Thu Dec  5 11:59:29 2019.
Error:
 Problem: conflicting requests
  - nothing provides perl(Import::Into) needed by
perl-utf8-all-0.024-7.el8.noarch
  - nothing provides perl(PerlIO::utf8_strict) needed by
perl-utf8-all-0.024-7.el8.noarch
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use
not only best candidate packages)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Fedora-Rawhide-20191205.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
6 of 43 required tests failed, 5 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 11/151 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-Rawhide-20191204.n.0):

ID: 493964  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/493964
ID: 493965  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/493965
ID: 494052  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/494052

Old failures (same test failed in Fedora-Rawhide-20191204.n.0):

ID: 493912  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/493912
ID: 493927  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/493927
ID: 493928  Test: x86_64 Server-dvd-iso server_cockpit_default **GATING**
URL: https://openqa.fedoraproject.org/tests/493928
ID: 493940  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/493940
ID: 493953  Test: x86_64 Workstation-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/493953
ID: 493978  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/493978
ID: 493987  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/493987
ID: 494044  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/494044
ID: 494045  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/494045

Soft failed openQA tests: 11/151 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-Rawhide-20191204.n.0):

ID: 493914  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/493914
ID: 493917  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/493917
ID: 493938  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/493938

Old soft failures (same test soft failed in Fedora-Rawhide-20191204.n.0):

ID: 493906  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/493906
ID: 493907  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/493907
ID: 493915  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/493915
ID: 493955  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/493955
ID: 493980  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/493980
ID: 494010  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/494010
ID: 494011  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/494011
ID: 494043  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/494043

Passed openQA tests: 113/151 (x86_64)

Skipped gating openQA tests: 5/151 (x86_64)

New skipped gating tests (same test not skipped in Fedora-Rawhide-20191204.n.0):

ID: 493969  Test: x86_64 KDE-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/493969
ID: 493970  Test: x86_64 KDE-live-iso desktop_terminal **GATING**
URL: https://openqa.fedoraproject.org/tests/493970
ID: 493972  Test: x86_64 KDE-live-iso base_system_logging **GATING**
URL: https://openqa.fedoraproject.org/tests/493972
ID: 493973  Test: x86_64 KDE-live-iso base_update_cli **GATING**
URL: https://openqa.fedoraproject.org/tests/493973

Old skipped gating tests (same test skipped in Fedora-Rawhide-20191204.n.0):

ID: 493926  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/493926

Skipped non-gating openQA tests: 12 of 153

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
Used swap changed from 10 MiB to 8 MiB
System load changed from 0.45 to 0.64
Previous test data: https://openqa.fedoraproject.org/tests/493242#downloads
Current test data: https://openqa.fedoraproject.org/tests/493948#downloads

Installed system changes in test x86_64 universal install_package_set_kde: 
Used swap changed from 10 MiB to 3 MiB
System load changed from 1.20 to 0.85
Average CPU usage changed from 41.97142857 to 28.74285714
Previous test data: https://openqa.fedoraproject.org/tests/493305#downloads
Current test data: 

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

[Marius Schwarz]

Am 05.12.19 um 09:03 schrieb Nicolas Mailhot via devel:
> Really, we should try to change the default to Azerty or the Russian
> layout for a release. That would teach qwerty users what is hostile to
> users of other layouts or not.
It was in the past, and i.e. a live disk is still defaulting to the US
keyboard layout,
so all !US/UK citizens know the problem ;)

best regards,
Marius

___
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 update spam (was: [Fedora Update] [comment] nbdkit-1.17.1-2.fc32)

[Richard W.M. Jones]

https://github.com/fedora-infra/bodhi/issues/3831

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
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

Unresponsive maintainer: anujmore / Anuj More

[Vít Ondruch]

Hi Anuj,

I am starting unresponsive maintainer process [0], because I am trying
to contact you in attempt to fix [1] after years. Your last action I am
aware of is granting permissions to rubygem-lumberjack [2], but that is
already almost two years and unfortunately, neither your other packages
are a not in best shape, I speak namely about:


rubygem-connection_pool (which where this started [1]).

rubygem-faker (this was never imported into repository [3])

rubygem-faraday

rubygem-lumberjack (well, this is maintaned by jackorp nowadays, but he
is not the POC)


So Anuj, are you with us? Or does anybody know how to contact Anuj?


Vít



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

[1] https://pagure.io/releng/issue/7523

[2] https://bugzilla.redhat.com/show_bug.cgi?id=960064#c10

[3]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NLUA3MWX2XDL3BOGWMDWBAAKAMAF2VP7/

___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[John M. Harris Jr]

On Thursday, December 5, 2019 12:57:15 AM MST Nicolas Mailhot via devel wrote:

> Let’s get real, in most businesses, the data will already be available
> in a network share, a common database, etc. Trying to perform fine-
> grained control checks on the mass of data businesses routinely
> manipulate is a loosing game. You always end up needing to trust
> humans.

Let's get real. In most business, the data will also be available in a network 
share. Trying to perform proper separation of permissions is the appropriate 
method of preventing unauthorized users from gaining that data. You don't need 
to "trust humans", other than those who do have access to the data.

> That’s even the case in ultra-secure environments like the NSA. How do
> you think wikileaks happened?

No.

-- 
John M. Harris, Jr.
Splentity

___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[John M. Harris Jr]

On Thursday, December 5, 2019 1:03:50 AM MST Nicolas Mailhot via devel wrote:
> That works in the GUI. All the low-level parts (including in anaconda
> terminal, right after it asked the user to choose a layout) are not
> configured properly by the distribution and will fallback to qwerty.

That's the case, until you actually install the system with it set globally. 
That is most likely because the livesystems are built for, I suppose, US 
QWERTY, and Anaconda devs didn't take switching to vttys into consideration 
there.

> Really, we should try to change the default to Azerty or the Russian
> layout for a release. That would teach qwerty users what is hostile to
> users of other layouts or not.

There is no "default", there is only what the live images are built with. 

-- 
John M. Harris, Jr.
Splentity

___
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: Modularity and all the things

[Brian (bex) Exelbierd]

On Wed, Nov 20, 2019 at 12:13 PM Petr Pisar  wrote:

> On 2019-11-19, John M. Harris Jr  wrote:
> > On Tuesday, November 19, 2019 4:42:31 AM MST Petr Pisar wrote:
> >> Manual work. Random commiters skipping them.
> >
> > If your goal is to make it so that "Random commiters" are packagers,
> that's
> > going to fall flat very quickly - as they'll just throw one version of
> the
> > package in, never think about it again. That is an untenable situation.
> >
> No. Random commiter is some one who does not know that the two
> branches have to be kept in synchronization. In other words someone else
> than the maintainer. E.g. If there is a guideline change or a SONAME
> bump then somebody touches your package.
>

While not perfect, this would be an ideal use of the README file in the
master branch.  This could specify things like, where to report bugs, if a
proven packager should try to contact the customary maintainer in advance,
if possible, how branches are maintained, etc.

regards,

bex



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


-- 
Brian "bex" Exelbierd (he/him/his)
RHEL Product Management & Community Architect
@bexelbie | http://www.winglemeyer.org
bexel...@redhat.com
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[John M. Harris Jr]

On Wednesday, December 4, 2019 8:44:18 PM MST Kevin Kofler wrote:
> How would that work? The shell runs on the server. The SSH agent runs on the
>  client, the only one that has the private key. How can the SSH agent know
> that it is talking to your "fake shell" and not to an attacker's fake "fake
> shell"? This needs to be part of the protocol, not hacked onto it. 

The very same way that it already knows when it's talking to `ssh` on a remote 
server. You've already verified the fingerprint, either manually or using DNS.

-- 
John M. Harris, Jr.
Splentity

___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[John M. Harris Jr]

On Thursday, December 5, 2019 2:56:22 AM MST Lennart Poettering wrote:
> Uh, first of all plain full disk encryption like we set it up
> typically on Fedora provides confidentiality, not integrity. For the
> OS image itself you want integrity though, confidentiality is not
> needed (after all anyone can download Fedora from the Internet,
> everyone knows all the bits and bytes in it anyway, it's inherently
> public information, there's zero point in encrypting it).

I have to disagree. The system itself is not just the list of packages 
installed, but can certainly include software that an individual or company 
wrote themselves or purchased , and do not wish to lose to a breach. This also 
includes global configuration files, which may include, for example, a VPN 
configuration, network configuration and so on.

> Unless you combine dm-crypt with dm-integrity (which we currently
> generally do not do), or you use dm-verity you are not actually
> protecting the OS from undetected modification.

Well, you are, in that the average attacker have to break or steal a key to 
decrypt the drive first. Sure, it wouldn't stop a sophisticated attack.

> And there's no point in encrypting /boot, because that contains only
> public information too. If you want to protect your boot chain, use
> something like a complete SecureBoot chain, but that too is something
> we currently don't actually support on Fedora. (because initrds are
> not verified).

This is not generally true either. Encrypting /boot helps to ensure that /boot 
is not modified, and is generally paired with GRUB signature validation. In 
some setups, this GRUB configuration is moved to flash storage.

> Anyway, figure out your threat model, and figure out how you want to
> protect what, and understand that for different parts of the
> installation different rules apply.

I don't believe this as the case, as specified above.

> And yes, I think encrypting the home directory with the user's own password
> makes most sense.

I suppose that's a good *start*, where users wouldn't use encryption 
otherwise.

-- 
John M. Harris, Jr.
Splentity

___
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: Should we discontinue the Python Classroom Lab?

[Benson Muite]

On 12/5/19 1:44 PM, Miro Hrončok wrote:

Hello,

I'd like to know whether it makes sense to continue maintaining and 
producing the Fedora Python Classroom Lab.
Do any schools use this?  Possibly an edition for use in a 
school/university computer lab or internet cafe may be more useful, with 
less focus on Python and better support for thin clients may be more 
helpful.


It has problems:

 - no issue tracker, I don't even know if there are users with issues
   - there has simple been close to zero feedback, maybe nobody uses 
this?


 - the website is horribly outdated: 
https://pagure.io/fedora-websites/issue/962


 - some Fedora versions weren't built:
   - I wasn't notified when F29 wasn't built
   - there was no way to get it fixed ex-post
   - https://pagure.io/releng/issue/7922

 - Docker is broken
   - one of the main ideas was to produce a Docker image
   - the Docker instructions on the download page [4] are not working
   - not even when replaced with podman
   - I have no idea how to fix it
   - I know no way to upload to official dockerhub [5]

 - Vagrant experience is not good enough
   - one of the main ideas was to produce a Vagrant box/image
   - I know no way to upload to official Vagrant thing [6]
   - downloading the box manually is tedious


The absolute lack of feedback makes is hard to dedicate time to 
actually persuade and fix the problems.



[1] https://labs.fedoraproject.org/en/python-classroom/
[2] https://fedoramagazine.org/introducing-python-classroom-lab/
[3] https://fedoraproject.org/wiki/Changes/PythonClassroomLab
[4] https://labs.fedoraproject.org/en/python-classroom/download/
[5] https://hub.docker.com/_/fedora/
[6] https://app.vagrantup.com/fedora/


___
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: Suggestion for Fedora change proposal: -Bsymbolic-functions default in LDFLAGS

[Petr Pisar]

On 2019-12-04, Paulo César Pereira de Andrade
 wrote:
> Em qua., 4 de dez. de 2019 às 10:16, Tom Hughes 
> escreveu:
>> If I understand correctly then it will also mean that LD_PRELOAD will
>> not work for any call made from the library to itself, but would
>> still work for calls made from other libraries.
>
>   Not fool proof checked, but I believe this is what would happen.
>   Usually one wants to only LD_PRELOAD to replace some glibc symbol,
>   for some kind of debug, but any library where there valid usages of
>   LD_PRELOAD should not be linked with -Bdynamic-functions.
>
Like when testing the compiled library in %check phase of a spec file.

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

Last chance to vote for FESCo

[Pete Walter]

Go vote now before the vote closes! Otherwise you'll miss this crucial chance 
to choose whether Fedora should support modularity or not.

https://elections.fedoraproject.org/

Pete
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Marius Schwarz]

Hi,

Am 05.12.19 um 10:33 schrieb Lennart Poettering:
>>> Also note that on Fedora Workstation we default to suspend-on-idle
>>> these days. i.e. when you don't actually work on the laptop the laptop
>>> is suspended and not reachable via SSH at all, hence adding
>>> systemd-homed doesn't make anything worse in that regard...
>> How do you wanne access data on your homeserver, when you are at
>> work?
> Fedora Workstation is — as the name suggests — a workstation OS. It
> enforces policies by deault (such as suspend-on-idle) that are not
> appropriate for a server.
My "workstation" -> is <- my homeserver, or do you have a 19" data rack 
in your home, just to be able to suspend your "workingstation", when you
go to your actual work? No, you don't :) And i don't speculate if you
either have a Laptop with all your data on it or a big pc to work with,
which is fast & has big storages and good GFX capabilities, because it
will be something i did not imagine. So don't assume, you know how
people use their stuff, make something universal. IMHO systemd and it's
components are there to start a system, not to control it afterwards.
That is out of systemds business.

> Which has nothing to do with systemd-homed btw, it's the existing
> Fedora Workstation behaving that way.

Quite right, so why do you wanne take control of it?


> Yeah, isn't it great that when you leave your laptop on your desk
> unattended you know for sure it's securely locked after a while and
> can only be unlocked from you again with your pw?

As long as my running system software does not have any major flaws, I
already sleep well, if it gets stolen.

There are very cool components, most of the users have no knowledge
about, that auto lock your system, when you leave the physical area
around your laptop. It's already implemented in Fedora today. i.e. via
detecting the absence of BT beacons (of any sort) in the near vicinity
of the laptop. 

With FDE running and "Suspend-to-disk" selected in your screensafer
settings, you get asked for your password on hw wakeup before your
system gets back running. If someone wants to use such things, he
already can.

Where is the advantage of homed, considering, that only encrypting
/home, is a major security flaw by itself. All your goals are already
there and it's more useful and secure too :) I really have a problem
understanding why you wanne implement a security flaw and call it "better".

If you wanne improve security, please focus on userfriendlyneess for
things like "disabling unused usb ports"/"whitelist for usb
ids"/"insecure Highspeed USB network adapter detection"  same for any
plugable port you have in your hw. And last, but not least, "motherboard
serial number validation on wakeup" to counter the switch of hw components.

> I love you too, my friend.

Cu :D

Best regards,
Marius
___
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

Should we discontinue the Python Classroom Lab?

[Miro Hrončok]

Hello,

I'd like to know whether it makes sense to continue maintaining and producing 
the Fedora Python Classroom Lab.


It has problems:

 - no issue tracker, I don't even know if there are users with issues
   - there has simple been close to zero feedback, maybe nobody uses this?

 - the website is horribly outdated: https://pagure.io/fedora-websites/issue/962

 - some Fedora versions weren't built:
   - I wasn't notified when F29 wasn't built
   - there was no way to get it fixed ex-post
   - https://pagure.io/releng/issue/7922

 - Docker is broken
   - one of the main ideas was to produce a Docker image
   - the Docker instructions on the download page [4] are not working
   - not even when replaced with podman
   - I have no idea how to fix it
   - I know no way to upload to official dockerhub [5]

 - Vagrant experience is not good enough
   - one of the main ideas was to produce a Vagrant box/image
   - I know no way to upload to official Vagrant thing [6]
   - downloading the box manually is tedious


The absolute lack of feedback makes is hard to dedicate time to actually 
persuade and fix the problems.



[1] https://labs.fedoraproject.org/en/python-classroom/
[2] https://fedoramagazine.org/introducing-python-classroom-lab/
[3] https://fedoraproject.org/wiki/Changes/PythonClassroomLab
[4] https://labs.fedoraproject.org/en/python-classroom/download/
[5] https://hub.docker.com/_/fedora/
[6] https://app.vagrantup.com/fedora/

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

Fedora without compressed instruction support

[Billa Surendra]

Dear David Abdurachmanov,

I have seen your presentation about fedora bootstrap on RV64, it was very
nice presentation actually. I am planning to boot a RISC-V Fedora on QEMU
Emulator, but I want to do some changes in fedora distro. Fedora distro
without compressed instruction support require for me, for this I have
written some steps where I can do changes. This steps completely I have
taken from your presentation. Please correct my steps whether I am going in
correct way or not ? I am new to fedora as well as bootstrap process.

Steps:

1. Installing QEMU (In x86 fedora host PC)
2. Installing GNU cross compiler tool chain (In this step I have installed
tool chain *https://github.com/riscv/riscv-gnu-toolchain
 *(RV64IMAFD support) in
fedora 86 host PC).
3. Install Berkly bootloader (In this step I have installed bootloader
*https://github.com/riscv/riscv-pk
* in fedora x86 host pc).
4. Linux kernel + basic rootfs (In this step taken Linux kernal from
*https://www.kernel.org/
* and cross compiled with above tool chain,
created basic rootfs).


>From Here I am not understanding the steps

5. Cross compile  and Install "RPM" packages and dependencies (where I can
get RPMs and dependencies list, after cross compiling RPMs whare I have to
install ?).
6. Install pre build RPMS (no idea about this step).
7. Rebuild RPMS from SRPMs natively (no idea about this step).
8. Install the new RPMS (no idea about this step).
9. Build stage4 image (no idea about this step).

Please correct my steps and give the solutions for step (5-9).

Thanks

Billa
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Lennart Poettering]

On Do, 05.12.19 00:40, Marius Schwarz (fedora...@cloud-foo.de) wrote:

> Am 04.12.19 um 02:02 schrieb Chris Murphy:
> > Anaconda custom partitioning has a per mount point encryption option.
> > I can LUKS encrypt only the volume mounted at /home. And if I do this,
> If you do this, someone can manipulate your system to trojan horse your
> passwords,
> when he has physical access to it.
>
> Full-Diskencryption ( /boot included ) is the only way to protect the
> system itself.
> Anything else is simply not secure.

Uh, first of all plain full disk encryption like we set it up
typically on Fedora provides confidentiality, not integrity. For the
OS image itself you want integrity though, confidentiality is not
needed (after all anyone can download Fedora from the Internet,
everyone knows all the bits and bytes in it anyway, it's inherently
public information, there's zero point in encrypting it).

Unless you combine dm-crypt with dm-integrity (which we currently
generally do not do), or you use dm-verity you are not actually
protecting the OS from undetected modification.

And there's no point in encrypting /boot, because that contains only
public information too. If you want to protect your boot chain, use
something like a complete SecureBoot chain, but that too is something
we currently don't actually support on Fedora. (because initrds are
not verified).

Anyway, figure out your threat model, and figure out how you want to
protect what, and understand that for different parts of the
installation different rules apply. And yes, I think encrypting the
home directory with the user's own password makes most sense.

Lennart

--
Lennart Poettering, Berlin
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Lennart Poettering]

On Do, 05.12.19 00:21, Marius Schwarz (fedora...@cloud-foo.de) wrote:

> Am 03.12.19 um 09:07 schrieb Lennart Poettering:
> > Also note that on Fedora Workstation we default to suspend-on-idle
> > these days. i.e. when you don't actually work on the laptop the laptop
> > is suspended and not reachable via SSH at all, hence adding
> > systemd-homed doesn't make anything worse in that regard...
>
> How do you wanne access data on your homeserver, when you are at
> work?

Fedora Workstation is — as the name suggests — a workstation OS. It
enforces policies by deault (such as suspend-on-idle) that are not
appropriate for a server.

Which has nothing to do with systemd-homed btw, it's the existing
Fedora Workstation behaving that way.

> The system will idle, will go into suspend and you can't access it
> anymore?

Yeah, isn't it great that when you leave your laptop on your desk
unattended you know for sure it's securely locked after a while and
can only be unlocked from you again with your pw?

> I really hope, it's easily configureable, otherwise it will end up here
> "dnf erase".

I love you too, my friend.

Lennart

--
Lennart Poettering, Berlin
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Marius Schwarz]

Am 05.12.19 um 01:13 schrieb John M. Harris Jr:
>> Full-Diskencryption ( /boot included ) is the only way to protect the
>> system itself.
>> Anything else is simply not secure.
> systemd-homed doesn't depend on /etc/passwd or /etc/shadow for
> authentication. By all means its security guarantees should be
> evaluated.
> https://github.com/systemd/systemd/pull/14096

It does not need to, if your system is open to any physical abuser, he
simply can exchange the tool to unlock the drive,
get the password, send it to the attacker and unlock the drive. Nothing
has changed for the user, but it got compromised.

And encrypting only parts of your system makes it extrem easy to tamper it.

and btw.. nothing stops an attacker from waiting for you to unlock the
drive for him, and exfiltrate your data when it's active.

System security needs four major anchors to rely on:

a full disc encryption
a good, not backdoored encryption system
secure programs 
and secure passcodes

if you only partly encrypt your disk, your data is only be protected
against a random theft and you have to enter your password
anyway to unlock it, so you also can encrypt the entire system. There
will be no extra work for you to do ;)

If you have to worry about someone instantly cooling your RAM down to
protect in-memory crypto keys after seizing your laptop, it's time to
rethink your lifestyle ;)


Best regards,
Marius
___
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

[Bug 1779900] perl-Archive-Extract-0.84 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
FEDORA-2019-5512be361d has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-5512be361d

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1779900] perl-Archive-Extract-0.84 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
FEDORA-2019-71bee7d558 has been submitted as an update to Fedora 31.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-71bee7d558

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1779900] perl-Archive-Extract-0.84 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
 CC|ppi...@redhat.com   |
   Fixed In Version||perl-Archive-Extract-0.84-1
   ||.fc32
   Doc Type|--- |If docs needed, set a value



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1779903] perl-Compress-Raw-Zlib-2.092 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Compress-Raw-Zlib-2.09
   ||2-1.fc32
 Resolution|--- |RAWHIDE
Last Closed||2019-12-05 08:45:20



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1779901] perl-Compress-Raw-Bzip2-2.092 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Compress-Raw-Bzip2-2.0
   ||92-1.fc32
 Resolution|--- |RAWHIDE
Last Closed||2019-12-05 08:21:42



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org