date:20120327

Re: httpd 2.4 is coming, RFC on module packaging draft

2012-03-27 Thread Jóhann B. Guðmundsson


On 03/27/2012 12:53 AM, Dennis Jacobfeuerborn wrote:

I disagree. Since this is a major update that gets introduced together with
a new Fedora version this opportunity should be used to make switches like
these. Otherwise you'll be forced to either keep this compat stuff around
for a long time (given the long apache release cycles) or remove it with a
minor update when people least expect it.


I agree on you disagreement.

We are very good at inventing and implementing the latest and the 
greatest but terribly at removing the legacy cruff at the same time, 
which results in half baked implementation leaving various things in 
compat mode and half removed from the distribution/install.


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: httpd 2.4 is coming, RFC on module packaging draft

2012-03-27 Thread Nicolas Mailhot


Le Lun 26 mars 2012 22:09, Chris Adams a écrit :
 Once upon a time, Nicolas Mailhot nicolas.mail...@laposte.net said:
 The following is going to kill pretty much every packaged webapp unless they
 are changed now:

 https://httpd.apache.org/docs/2.4/upgrading.html#access

 Did you read this part:

   The old access control idioms should be replaced by the new
authentication mechanisms, although for compatibility with old
configurations, the new module mod_access_compat is provided.

 It would be easy to include mod_access_compat in the Fedora default
 config for a release or two while the compat config is deprecated (and
 noted in the release notes as such).

Sure. But right now there does not seem to be a plan one way or the other, so
now that http 2.4 is built rawhide webapps are broken.

-- 
Nicolas Mailhot

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fwd: Connotation analysis for Fedora Project codenames

2012-03-27 Thread Andrew Haley

On 03/26/2012 11:01 PM, Robert 'Bob' Jensen wrote:
 As I already pointed out - the process is open. Anybody can step
 into in the early phase of naming selection and comment the 
 potential problems. And I believe the Board members will think
 about the concerns raised (at least me ;-). 
 
 So personally I'd like to avoid any strict rule/policy as it could 
 hurt our community, we don't have a proper set of skills to do 
 the full analysis during the Board turn and I really hope with help 
 provided by community we  can avoid the naming problems in the 
 future - just we need your, community, input.

I'm sure that's the right approach.

 Any thoughts?
 
 PS: I like Christoph's comment in ticket - that as an international 
 project we should be proud of our diversity. It is a chance and 
 a burden at the same time, Fedora will face this problem often and 
 we can do our best to respect others and their views.

Indeed, but let's not get carried away, lest we end up in a situation
where no town that ever had a brewery can be named because it might
theoretically offend a religion that forbids alcohol consumption.
I'm sure you'll be sensible.

Andrew.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: urandom vs haveged

2012-03-27 Thread Roberto Ragusa

On 03/27/2012 05:23 AM, Gregory Maxwell wrote:
 On Mon, Mar 26, 2012 at 6:55 PM, Chris Murphy li...@colorremedies.com wrote:
 So then the question is, if urandom is what's recommended, are faster 
 substitutes just as good? If they are just as good, then why aren't they the 
 first recommendation? And if this step is superfluous, then I'd suggest 
 documentation be changed to eliminate the suggestion altogether.
 
 Personally, I setup dmcrypt (w/o luks) first using /dev/urandom as the
 key and one of the secure block modes (e.g. aes-lrw or aes-essiv).
 Then I fill the dmcrypt device with /dev/zero.  This goes fairly fast,
 filling the device with securely encrypted zeros.
 
 Then I drop the volume and set up luks normally.

Nice trick. Does this saturate the disk speed?

Last time I had to do this I compiled my own random generator,
using some code from a research article.
That was fast C code, when compiled for x86_64 with good gcc
options the speed (/dev/null) was 1.75GB/s (!!!).


-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: urandom vs haveged

2012-03-27 Thread Pádraig Brady

On 03/26/2012 11:55 PM, Chris Murphy wrote:

On Mar 26, 2012, at 4:31 PM, Pádraig Brady wrote:

Well if you're just writing huge amounts of random data
to clear existing space, then you don't need it to be cryptographically
secure.
Why are you doing this exactly? Would /dev/zero suffice?

In every supposed best practice case of dm-crypt LUKS setup, urandom is used
by example. Including by Red Hat and Fedora Projects. The Fedora link says:
You're looking at a process that takes many hours, but it is imperative to
do this in order to have good protection against break-in attempts. Just let
it run overnight.

http://www.redhat.com/summit/2011/presentations/summit/taste_of_training/wednesday/Strickland_On_Disk_Encryption_with_RHEL.pdf

http://fedoraproject.org/wiki/Implementing_LUKS_Disk_Encryption

http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption-Manually_Encrypting_Directories-Step_by_Step_Instructions.html

So then the question is, if urandom is what's recommended, are faster
substitutes just as good? If they are just as good, then why aren't they the
first recommendation? And if this step is superfluous, then I'd suggest
documentation be changed to eliminate the suggestion altogether.

Well I can only think of two reasons for writing random data.
1. Ensure all existing data is overwritten (zeros would do just as well on
modern drives)
2. Homogenize written (with luks data) and nonwritten parts of the drive,
so that you can't determine the extent of the real encrypted data.

66 matches

Mail list logo