date:20200602

Re: Fedora 33 Self-Contained Change proposal: Drop mod_php

2020-06-02 Thread Peter Pentchev

On Tue, Jun 02, 2020 at 07:47:12PM -0700, John M. Harris Jr wrote:
> On Tuesday, June 2, 2020 2:05:01 AM MST Joe Orton wrote:
> > On Sat, May 30, 2020 at 11:13:35AM +0200, Zbigniew Jędrzejewski-Szmek
> > wrote:
> > > On Thu, May 28, 2020 at 03:53:26PM -0400, Ben Cotton wrote:
> > > 
> > > > == Detailed Description ==
> > > > By default php-fpm is used for a few versions. mod_php is not
> > > > supported for threaded modules. mod_php usage also increases security
> > > > risk, sharing the same process than httpd.
> > > > 
> > > > Drop mod_php from php build. This will only affect user of httpd in
> > > > "prefork" mode, which will also use php-fpm.
> > > > 
> > > > php-fpm is already used but most users of httpd and nginx without any
> > > > issue.
> > 
> > > 
> > > Based on the replies downthread, it seems that some people are still
> > > using it and want to keep it...
> > 
> > 
> > If the existence of non-zero user demand blocked removal of defunct 
> > technology in Fedora I guess we'd still be shipping SysV init.  
> > 
> > We made the switch from forked-httpd + mod_php to threaded-httpd +
> > php-fpm by default in Fedora 27, so we've spread this transition over 
> > six full release cycles.  We've had AFAIK *zero* bug reports about
> > making the default switch.
> > 
> > 
> > > Is mod_php a maintainance burder and/or a noticable installation
> > > overhead when not used? And if it is, would additional help with the
> > > maintainance that was offered make it easier to keep?
> > 
> > 
> > I'm not seeing any technical argument in this thread to support keeping 
> > mod_php.  If there were, that would be interesting, but otherwise I 
> > think the package owner should be trusted and empowered to make this 
> > change.
> > 
> > Regards, Joe
> 
> If it's dropped, it wouldn't really be possible for me to make a mod_php 
> package to replace it due to the integration, so I can't really see a way of 
> keeping a compat package if it's removed, and keeping it around doesn't break 
> anything.

Do you have an application that absolutely cannot work using php-fpm, or
is it a matter of "must set some time aside to migrate and test
everything after a switch from mod_php to fpm"?

If it's the first, people have repeatedly stated that they want to know
what it is and why. Also, people have repeatedly stated that mod_php is
strongly recommended against by upstream. Also, people have repeatedly
stated that having to support mod_php blocks future work.

If it is the second, unfortunately that is true of many changes.
Sometimes we have to do some work to adapt to a new, better way of doing
things. Sometimes we can see at once that the new way is indeed better;
sometimes it takes us months or even years to realize that. And yes,
there may be particular circumstances when the benefits of the new way
do not really outweigh the benefits that the old way provided, but it is
not easy for me to imagine a situation when a switch from mod_php to
php-fpm would break things. Yes, I can, yes, I know that one can install
more modules, make some PHP applications use shared server memory and
whatnot; still, it seems to me that ultimately there are better ways to
handle most of these.

The vast, overwhelming majority of installations do not *need* mod_php.

The vast, overwhelming majority of installations would *benefit* from
a switch to php-fpm.

The vast, overwhelming majority of installations *currently* using
mod_php are doing it because of conventional wisdom ("this is the way to
set up a PHP site") that is rooted in the times when php-fpm
*did not exist* - so it's much more of "this was the only possible way
to set up a PHP site back then" than "this is the best way to set up
a PHP site now".

Yep, migration needs work. Acknowledged. The same could be said of
changing an init system, changing a default syslog implementation,
changing the way a database server is configured, changing the defaults
for a proxy server's configuration... and so many more.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

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: Supporting hibernation in Workstation ed., draft 1

2020-06-02 Thread Chris Murphy

On Tue, Jun 2, 2020 at 8:42 PM John M. Harris Jr  wrote:

> In what way is it incompatible with UEFI Secure Boot?

Secure Boot does boot verification. Hibernation right now doesn't. And
that makes it a Secure Boot loophole. And that makes it incompatible
with Secure Boot.

It's not a new idea, it's been this way for a while. And so have the complaints.
https://lwn.net/Articles/523367/

 initramfs are signed, and the resume image is for that kernel, how is this an
> issue?

The initramfs is not signed.

> What if swap is on LUKS?

No signature. No integrity. It is a net reduction in the protection
provided by Secure Boot - e.g. it can't detect intentional corruption
that could crash the system or even cause more corruption and eventual
data loss as the system runs.

> If kernel lockdown is what disables this, we should look at fixing kernel
> lockdown so that it doesn't break hibernation. This is definitely a security
> decision that we shouldn't be imposing on the masses needlessly, in my
> opinion.

Instead you propose imposing a loophole for attackers to easily deploy
malware needlessly. Do you really not see how this is an untenable
position for Fedora?

-- 
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: Supporting hibernation in Workstation ed., draft 1

2020-06-02 Thread Chris Murphy

On Tue, Jun 2, 2020 at 10:35 PM Samuel Sieb  wrote:
>
> On 6/2/20 9:25 PM, Chris Murphy wrote:
> > On Tue, Jun 2, 2020 at 8:33 PM John M. Harris Jr  
> > wrote:
> >>
> >> On Sunday, May 31, 2020 11:45:40 AM MST Chris Murphy wrote:
> >>> On Sat, May 30, 2020 at 9:26 PM Tony Nelson
> >>>  wrote:
> >>>
> 
> 
>  On 20-05-30 21:02:11, Chris Murphy wrote:
> 
> ...
> 
> > Full disk encryption doesn't adequately secure the hibernation image
> > either. Authenticated encryption (signing as well as encryption) is
> > needed to verify the image hasn't been tampered.
> 
> 
> 
>  What can an attacker do other than corrupt the data?  It is encrypted.
> >>>
> >>>
> >>> You don't know, and neither do I. That's the problem.
> >>
> >> We do know. Nothing, really.
> >
> > You do not know the attacker, when possession was lost, what the
> > attacker knows, or how long they have access to ciphertext. And that's
> > because the attack hasn't happened yet. Yet you assert omniscience.
> > Gotcha.
>
> I don't understand this concern either.  How is it different than any
> encrypted filesystem?  If you don't trust the encryption, then what's
> the point?  What's the difference between an encrypted filesystem and an
> encrypted hibernation image that makes the image so insecure?

You trust the encryption only to provide confidentiality of your data
from the attacker. Not as a means of detecting an attack on your data.
And also this isn't really just user data, the hibernation image is
the kernel. If it's really compromised, it's a complete end run around
the guarantees of Secure Boot so necessarily it can't be weaker than
that implementation or the whole implementation is weakened. If it's
easier to exploit via the hibernation image, that's what attackers
will do.

An encrypted file system, again provides only confidentiality. There's
no integrity check. In fact you are equally susceptible to data
integrity problems whether your data is encrypted or not. You'd need a
dm-integrity option enabled (an option that can be done at the same
time as cryptsetup now), or you need to use Btrfs. Depending on your
threat model you might need to use one of the cyptographic hash
functions (dm-integrity provides hmac:sha256; and btrfs provides
sha256 and blake2b, looks like keyed hashing support is decently
likely to happen there as well). The keyed hashing function provides
integrity but also provides authenticity. You need the key to produce
valid writes. If you don't have the key, the writes you produce would
be immediately detected as bogus by the key holder.

Ergo you can trust your attacker can't see in /usr. But you don't
know, with encryption alone if you can trust /usr. It pretty much
comes down to trusting the hardware ECC in the drive, if you don't
have something that provides integrity.

-- 
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: Supporting hibernation in Workstation ed., draft 1

2020-06-02 Thread John M. Harris Jr

On Tuesday, June 2, 2020 9:45:45 PM MST Chris Murphy wrote:
> On Tue, Jun 2, 2020 at 10:28 PM Samuel Sieb  wrote:
>
> >
> >
> > I would expect that using an encrypted partition for swap should be
> > sufficient to allow it though.
>
>
> Unfortunately not. Encryption provides no integrity or authenticity.
> The original set of patches for signed and authenticated hibernation
> images called for the use of an HMAC for signing, and upstream
> considered this insufficient and asked why not use AES-GCM to provide
> a real AE (authenticated encryption) model.

In what way do you believe it's not sufficient?

> Not only is encryption alone inadequate, the signature verification
> model should ensure that the hibernation image being restored was
> created by the computer it is being restored to.

Why?

> I am not a cryptographer. And I can't do a better job of explaining
> it. But it's a problem. And my disappointment isn't relevant to the
> security issue. It's relevant from a UX perspective I suppose.

It's a severe UX issue that you cannot use a standard feature of normal 
systems, hibernation.

> But, I've also just spent two days trying to track down a new
> hibernation bug, resulting in fatal hibernation entry. Even without
> the Secure Boot issue, hibernation can be a problem that requires
> resources that are not finite. I had this working reliably several
> months ago, and I've exhausted my time and interest for now doing
> kernel regression testing and have literally no idea why it's
> consistently failing now. On three machines (one is a VM). I did
> report it upstream, I haven't gotten a reply yet (normal).
>
> There are two emails, bottom one is the first.
> https://lore.kernel.org/linux-pm/CAJCQCtQVGqxtZZTRgscT7e4inTacAd7KAmoNOz3gB4
> hf1nk...@mail.gmail.com/
 
>
> -- 
> Chris Murphy

-- 
John M. Harris, Jr.

___
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: Supporting hibernation in Workstation ed., draft 1

2020-06-02 Thread Chris Murphy

On Tue, Jun 2, 2020 at 10:28 PM Samuel Sieb wrote:
>
> I would expect that using an encrypted partition for swap should be
> sufficient to allow it though.

Unfortunately not. Encryption provides no integrity or authenticity.
The original set of patches for signed and authenticated hibernation
images called for the use of an HMAC for signing, and upstream
considered this insufficient and asked why not use AES-GCM to provide
a real AE (authenticated encryption) model.

Not only is encryption alone inadequate, the signature verification
model should ensure that the hibernation image being restored was
created by the computer it is being restored to.

I am not a cryptographer. And I can't do a better job of explaining
it. But it's a problem. And my disappointment isn't relevant to the
security issue. It's relevant from a UX perspective I suppose.

But, I've also just spent two days trying to track down a new
hibernation bug, resulting in fatal hibernation entry. Even without
the Secure Boot issue, hibernation can be a problem that requires
resources that are not finite. I had this working reliably several
months ago, and I've exhausted my time and interest for now doing
kernel regression testing and have literally no idea why it's
consistently failing now. On three machines (one is a VM). I did
report it upstream, I haven't gotten a reply yet (normal).

There are two emails, bottom one is the first.
https://lore.kernel.org/linux-pm/cajcqctqvgqxtzztrgsct7e4intacad7kamonoz3gb4hf1nk...@mail.gmail.com/

--
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: Supporting hibernation in Workstation ed., draft 1

2020-06-02 Thread Samuel Sieb


On 6/2/20 9:25 PM, Chris Murphy wrote:

On Tue, Jun 2, 2020 at 8:33 PM John M. Harris Jr  wrote:


On Sunday, May 31, 2020 11:45:40 AM MST Chris Murphy wrote:

On Sat, May 30, 2020 at 9:26 PM Tony Nelson
 wrote:




On 20-05-30 21:02:11, Chris Murphy wrote:

   ...


Full disk encryption doesn't adequately secure the hibernation image
either. Authenticated encryption (signing as well as encryption) is
needed to verify the image hasn't been tampered.




What can an attacker do other than corrupt the data?  It is encrypted.



You don't know, and neither do I. That's the problem.


We do know. Nothing, really.


You do not know the attacker, when possession was lost, what the
attacker knows, or how long they have access to ciphertext. And that's
because the attack hasn't happened yet. Yet you assert omniscience.
Gotcha.


I don't understand this concern either.  How is it different than any 
encrypted filesystem?  If you don't trust the encryption, then what's 
the point?  What's the difference between an encrypted filesystem and an 
encrypted hibernation image that makes the image so insecure?

___
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: Supporting hibernation in Workstation ed., draft 1

2020-06-02 Thread Samuel Sieb


On 6/2/20 7:41 PM, John M. Harris Jr wrote:

In what way is it incompatible with UEFI Secure Boot? If the kernel and
initramfs are signed, and the resume image is for that kernel, how is this an
issue? What if swap is on LUKS?


Do you understand how hibernation works?  It doesn't matter if the 
booting kernel is signed, everything will be replaced by what's on the 
disk.  The kernel you boot with does not even have to be the same one 
the hibernated image was booted with.  Someone could modify the 
in-memory image of the kernel on the disk or change some process to be 
running as root when it's resumed.  So it completely bypasses any 
protection that secure boot provides.  I'm inclined to say let me have 
that insecurity if I want, but I think there are rules about what's 
allowed if secure boot is enabled.


I would expect that using an encrypted partition for swap should be 
sufficient to allow it though.

___
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: Supporting hibernation in Workstation ed., draft 1

2020-06-02 Thread Chris Murphy

On Tue, Jun 2, 2020 at 8:33 PM John M. Harris Jr  wrote:
>
> On Sunday, May 31, 2020 11:45:40 AM MST Chris Murphy wrote:
> > On Sat, May 30, 2020 at 9:26 PM Tony Nelson
> >  wrote:
> >
> > >
> > >
> > > On 20-05-30 21:02:11, Chris Murphy wrote:
> > >
> > >   ...
> > >
> > > > Full disk encryption doesn't adequately secure the hibernation image
> > > > either. Authenticated encryption (signing as well as encryption) is
> > > > needed to verify the image hasn't been tampered.
> > >
> > >
> > >
> > > What can an attacker do other than corrupt the data?  It is encrypted.
> >
> >
> > You don't know, and neither do I. That's the problem.
>
> We do know. Nothing, really.

You do not know the attacker, when possession was lost, what the
attacker knows, or how long they have access to ciphertext. And that's
because the attack hasn't happened yet. Yet you assert omniscience.
Gotcha.


> A good option until then is to just take unsigned hibernation images and work
> like literally every other system. There's no reason to take away this
> functionality.

Why do you think it's good to tell users we support UEFI Secure Boot,
but then provide attackers a loop hole to get around it?




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

[389-devel] 389 DS nightly 2020-06-03 - 95% PASS

2020-06-02 Thread vashirov

https://fedorapeople.org/groups/389ds/ci/nightly/2020/06/03/report-389-ds-base-1.4.4.3-20200602gita0113b1.fc32.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

[EPEL-devel] Fedora EPEL 6 updates-testing report

2020-06-02 Thread updates

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fe619e5492   
golang-1.13.11-1.el6
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ffaa79c364   
sympa-6.2.56-1.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-989ca5d300   
mbedtls-2.7.15-1.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

qpid-proton-0.31.0-2.el6

Details about builds:



 qpid-proton-0.31.0-2.el6 (FEDORA-EPEL-2020-d8931a96aa)
 A high performance, lightweight messaging library

Update Information:

Resolved cmake issue with examples.    Rebased to 0.31.0.

ChangeLog:

* Mon Jun  1 2020 Irina Boverman  - 0.31.0-2
- Corrected cmake for c/cpp examples
- Resolved PROTON-2228
* Thu May 14 2020 Irina Boverman  - 0.31.0-1
- Rebased to 0.31.0


___
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

1 2 3 >

1 - 100 of 232 matches

Mail list logo