Re: Mounting an encrypted volume presents the volume to all users on a machine
On Tue, 2010-10-26 at 15:10 -0500, Bruno Wolff III wrote: > On Tue, Oct 26, 2010 at 13:16:41 -0600, > "Nathanael D. Noblet" wrote: > > > > Just out of curiosity... when are these being mounted? If we are talking > > about mounting a partition from a user session that's one thing and can > > easily make it user only accessible with a checkbox I guess. I'm > > wondering though, when you plug in a USB thumbdrive... don't all users > > have access? What's the difference here? Are we talking about system > > wide mounts like mine where only /home is encrypted?? > > This is where we should be going. Encryption is really irrelavent. Not necessarily. There's a case that the automount behaviour for an encrypted volume should be different from that of a non-encrypted volume. As I read it, it's also technically plausible, because you can know with 100% accuracy which user should have access to the encrypted volume - the user from whose session the passphrase was entered. This is not the case with unencrypted volumes. > The issue > should be if a removable device is inserted, who should have access to it > if it gets automounted. I would expect encrypted and unencrypted devices > to get the same treatment. The encrypted devices do already have a pop up, > so maybe that makes it not as much effort to ask a question when the device > is mounted. But I don't see otherwise why one would want to treat encrypted > and uncrypted removable devices differently. There's a technical issue; see above. And I can see a reasonable user expectation that on a multi-user system an encrypted volume should be mounted accessible only to the user who entered the passphrase, to be honest. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: policycoreutils needs cairo.
On Tue, 2010-10-26 at 13:01 +0530, Rahul Sundaram wrote: > On 10/26/2010 04:22 AM, Adam Williamson wrote: > > > > Having said that, I don't think this seems serious enough to be a > > blocker, though obviously we'd like the minimal install to be as minimal > > as possible. Does it cause major problems for any spins? I doubt it, I > > expect most of them will have cairo for one reason or another anyway. > > Can we make this such issues a blocker starting from the next release? > A minimal install should really be minimal. Otherwise, we have failed > and it does affect EC2 deployments among other things. it's a bit of a tricky line to draw. We have a size test that makes sure builds aren't over the targeted sizes, we could add a test that a minimal install doesn't go over a given size after installation, I guess. What size would be the target? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-10-26) NEW TIME!
Kevin Fenzi said the following on 10/26/2010 12:36 PM Pacific Time: > Following is the list of topics that will be discussed in the FESCo > meeting tomorrow at 18:30UTC (2:30pm EDT) in #fedora-meeting on > irc.freenode.net. > > = Followups = > > #topic Updates policy > > #351 Create a policy for updates - status report on implementation > https://fedorahosted.org/fesco/ticket/351 > #382 Implementing Stable Release Vision > https://fedorahosted.org/fesco/ticket/382 > > * Need work on stats to see trends with new policy. > * Need to investigate a 'new features' repo setup. > * Need to look at enforcement > > = New business = > > #416 Set EOL Date For Fedora 12 > https://fedorahosted.org/fesco/ticket/416 > > * Since F14 was pushed out a week, should we move EOL for F12 as well? > > Elections coming up. > > * Note that FESCo (and FAMSCo and Board) elections are coming up. > > = Fedora Engineering Services tickets = > > https://fedorahosted.org/fedora-engineering-services/report/6 > > = Open Floor = > > For more complete details, please visit each individual ticket. The > report of the agenda items can be found at > https://fedorahosted.org/fesco/report/9 > > If you would like to add something to this agenda, you can reply to > this e-mail, file a new ticket at https://fedorahosted.org/fesco, > e-mail me directly, or bring it up at the end of the meeting, during > the open floor topic. Note that added topics may be deferred until > the following meeting. > > kevin > We have some Fedora 15 features too. https://fedoraproject.org/wiki/Category:FeatureReadyForFesco John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 14 Final Release Declared GOLD
At the Fedora 14 Final Go/No-Go meeting today, the Fedora 14 Final Release was declared GOLD and ready for release on November 2, 2010. Thank you to everyone who made this on-time release possible! A reminder that the Fedora 14 Release Wide Readiness Meeting will take place on Thursday at 19:00 UTC (3 PM Eastern/ 12 PM Pacific) at irc.freenode.net #fedora-meeting https://fedoraproject.org/wiki/Release_Readiness_Meetings #fedora-meeting: Fedora 14 Final Release Go/No-Go Meeting http://fedoraproject.org/wiki/Go_No_Go_Meeting Meeting started by poelcat at 20:59:48 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-10-26/fedora-meeting.2010-10-26-20.59.log.html . Meeting summary --- * attendees: jlaska Oxf13 adamw poelcat dcantrell (and anyone on #fedora-meeting) (poelcat, 21:03:40) * Why are here and what does it mean? (poelcat, 21:03:51) * LINK: http://fedoraproject.org/wiki/Go_No_Go_Meeting (poelcat, 21:04:02) * Testing Status (poelcat, 21:05:10) * LINK: https://fedoraproject.org/wiki/Test_Results:Fedora_14_Final_RC1_Desktop (jlaska, 21:06:54) * LINK: https://fedoraproject.org/wiki/Test_Results:Fedora_14_Final_RC1_Install (jlaska, 21:07:07) * https://bugzilla.redhat.com/show_bug.cgi?id=646437 (jlaska, 21:13:14) * test matrices are clear (poelcat, 21:16:24) * Releng (poelcat, 21:18:12) * fesco/devel/etc (poelcat, 21:18:52) * the source DVD is 5gigs, but it was oversize last release too (poelcat, 21:19:27) * GOLD or Not? (poelcat, 21:32:48) * AGREED: Fedora 14 is declared GOLD (poelcat, 21:34:55) * ACTION: add DVD size issue to common bugs (poelcat, 21:35:06) * open discussion (poelcat, 21:35:55) * ACTION: poelcat to send GOLD email to the lists w/ reminder for release readiness meeting on Thursday (poelcat, 21:39:06) Meeting ended at 21:39:19 UTC. Action Items * add DVD size issue to common bugs * poelcat to send GOLD email to the lists w/ reminder for release readiness meeting on Thursday Action Items, by person --- * poelcat * poelcat to send GOLD email to the lists w/ reminder for release readiness meeting on Thursday * **UNASSIGNED** * add DVD size issue to common bugs People Present (lines said) --- * poelcat (57) * adamw (55) * jlaska (25) * Oxf13 (22) * fenris02 (15) * stickster (7) * brunowolff (5) * dcantrell (3) * bcl (2) * zodbot (2) * cyberpear (1) * rbergeron (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On Tue, Oct 26, 2010 at 14:07:53 -0700, Jesse Keating wrote: > -BEGIN PGP SIGNED MESSAGE- > > That's only if you give root the right to disable or load new selinux > policy. And the policy is tight enough. You need to not allow root shells or most processes the ability to read the keys out of memory or to write memory that will change how things work. I don't think targeted policy is locked down enough to stop that even if you don't allow root to disble selinux. > Seriously, there are machines on the public Internet with a published > root account. You're welcome to log in and try to do anything with them. Yeah, I know about one guy that offers a root password if you ask. I am not sure what policy he is running on that machine. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On 26/10/10 22:24, Gregory Maxwell wrote: > On Tue, Oct 26, 2010 at 4:10 PM, Bruno Wolff III wrote: >> This is where we should be going. Encryption is really irrelavent. The issue >> should be if a removable device is inserted, who should have access to it >> if it gets automounted. I would expect encrypted and unencrypted devices >> to get the same treatment. The encrypted devices do already have a pop up, >> so maybe that makes it not as much effort to ask a question when the device >> is mounted. But I don't see otherwise why one would want to treat encrypted >> and uncrypted removable devices differently. > > We don't know which of multiple users plugged the device in but we > know which user provided the key to decrypt the device. > > The existence of encryption shows that the user may care more about > the confidentiality of the data, and there is less of an previously > existing "installed base" of expectations about how an encrypted > volume works when you plug it in. This is exactly it. > If we wanted to get fancy (e.g. go beyond just a change in the default > modes) additional users could authenticate themselves to an already > mounted encrypted volume one at a time by providing the key. > > ::shrugs:: -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On 10/26/2010 04:05 PM, Bruno Wolff III wrote: > On Tue, Oct 26, 2010 at 14:18:55 -0400, >Przemek Klosowski wrote: >> >> Such user-differentiated authorization is provided by the filesystem >> access rights, ACLs and SELinux attributes. Note that unlike the first >> two mechanisms, SELinux can protect the data even for systems with >> compromised root---as someone said, SELinux can be configured so that >> you can tell people "here's the root password; now break into my computer". > > That's overstating things a bit. A root compromise is usually going to allow > working around selinux limitations. My point here is to distinguish between 'compromised root' and 'compromised overall system integrity'. Many (but not all) exploits are of the first kind (get a root shell, or change your EUID to zero). Of course the latter exploits can get around any security, as you say. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/26/2010 01:05 PM, Bruno Wolff III wrote: > On Tue, Oct 26, 2010 at 14:18:55 -0400, > Przemek Klosowski wrote: >> >> Such user-differentiated authorization is provided by the filesystem >> access rights, ACLs and SELinux attributes. Note that unlike the first >> two mechanisms, SELinux can protect the data even for systems with >> compromised root---as someone said, SELinux can be configured so that >> you can tell people "here's the root password; now break into my computer". > > That's overstating things a bit. A root compromise is usually going to allow > working around selinux limitations. That's only if you give root the right to disable or load new selinux policy. Seriously, there are machines on the public Internet with a published root account. You're welcome to log in and try to do anything with them. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzHQykACgkQ4v2HLvE71NWTLQCgqDG5fxdz5JIN9UHJgoKgjoTu nqIAn36jkuXDvxah49dukTjQ2hWyj5+q =TQbe -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-14 Branched report: 20101026 changes
Thomas Spura píše v Út 26. 10. 2010 v 22:23 +0200: > On Tue, 26 Oct 2010 21:15:03 +0200 > Dan Horák wrote: > > > Jesse Keating píše v Út 26. 10. 2010 v 12:01 -0700: > > > On 10/26/10 11:46 AM, Branched Report wrote: > > > > Updated Packages: > > > > > > > > tryton-1.6.1-1.fc14 > > > > --- > > > > * Tue Jul 27 2010 Dan Horák 1.6.1-1 > > > > - update to upstream version 1.6.1 > > > > > > > > * Thu Jul 22 2010 Dan Horák 1.6.0-3.1 > > > > - don't build docs on EL <= 5 > > > > > > This is not necessarily a freeze break, but fixing a tagging issue > > > with bodhi. > > > > And there was really some bad timing before the F-14 branching and > > cvs->git conversion because it was built with python 2.6 causing > > broken deps, new build is queued right now. > > But why? > I just got a broken deps mail about: > tryton has broken dependencies in the F-14 tree: > On x86_64: > tryton-1.6.1-1.fc14.noarch requires python(abi) = 0:2.6 > On i386: > tryton-1.6.1-1.fc14.noarch requires python(abi) = 0:2.6 > Please resolve this as soon as possible. > > And no such mail before... > > Something really odd was going on right now... due some bad timing (regular build vs. python 2.7 mass rebuild) the build that was included in the F-14 repo was 1.6.0-3.fc14 so I've asked rel-engs in a ticket to retag the latest one (higher NVR, 1.6.1-1.fc14) so it will appear in F-14. Unfortunately that one was built against the old python causing the broken deps you see above. Now Jesse will tag 1.6.0-3.fc14 back into F-14 and I will submit 1.6.1-1.fc14.1 as a regular update. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On Tue, Oct 26, 2010 at 4:10 PM, Bruno Wolff III wrote: > This is where we should be going. Encryption is really irrelavent. The issue > should be if a removable device is inserted, who should have access to it > if it gets automounted. I would expect encrypted and unencrypted devices > to get the same treatment. The encrypted devices do already have a pop up, > so maybe that makes it not as much effort to ask a question when the device > is mounted. But I don't see otherwise why one would want to treat encrypted > and uncrypted removable devices differently. We don't know which of multiple users plugged the device in but we know which user provided the key to decrypt the device. The existence of encryption shows that the user may care more about the confidentiality of the data, and there is less of an previously existing "installed base" of expectations about how an encrypted volume works when you plug it in. If we wanted to get fancy (e.g. go beyond just a change in the default modes) additional users could authenticate themselves to an already mounted encrypted volume one at a time by providing the key. ::shrugs:: -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-14 Branched report: 20101026 changes
On Tue, 26 Oct 2010 21:15:03 +0200 Dan Horák wrote: > Jesse Keating píše v Út 26. 10. 2010 v 12:01 -0700: > > On 10/26/10 11:46 AM, Branched Report wrote: > > > Updated Packages: > > > > > > tryton-1.6.1-1.fc14 > > > --- > > > * Tue Jul 27 2010 Dan Horák 1.6.1-1 > > > - update to upstream version 1.6.1 > > > > > > * Thu Jul 22 2010 Dan Horák 1.6.0-3.1 > > > - don't build docs on EL <= 5 > > > > This is not necessarily a freeze break, but fixing a tagging issue > > with bodhi. > > And there was really some bad timing before the F-14 branching and > cvs->git conversion because it was built with python 2.6 causing > broken deps, new build is queued right now. But why? I just got a broken deps mail about: tryton has broken dependencies in the F-14 tree: On x86_64: tryton-1.6.1-1.fc14.noarch requires python(abi) = 0:2.6 On i386: tryton-1.6.1-1.fc14.noarch requires python(abi) = 0:2.6 Please resolve this as soon as possible. And no such mail before... Something really odd was going on right now... -- Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On Tue, Oct 26, 2010 at 13:16:41 -0600, "Nathanael D. Noblet" wrote: > > Just out of curiosity... when are these being mounted? If we are talking > about mounting a partition from a user session that's one thing and can > easily make it user only accessible with a checkbox I guess. I'm > wondering though, when you plug in a USB thumbdrive... don't all users > have access? What's the difference here? Are we talking about system > wide mounts like mine where only /home is encrypted?? This is where we should be going. Encryption is really irrelavent. The issue should be if a removable device is inserted, who should have access to it if it gets automounted. I would expect encrypted and unencrypted devices to get the same treatment. The encrypted devices do already have a pop up, so maybe that makes it not as much effort to ask a question when the device is mounted. But I don't see otherwise why one would want to treat encrypted and uncrypted removable devices differently. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On Tue, Oct 26, 2010 at 14:18:55 -0400, Przemek Klosowski wrote: > > Such user-differentiated authorization is provided by the filesystem > access rights, ACLs and SELinux attributes. Note that unlike the first > two mechanisms, SELinux can protect the data even for systems with > compromised root---as someone said, SELinux can be configured so that > you can tell people "here's the root password; now break into my computer". That's overstating things a bit. A root compromise is usually going to allow working around selinux limitations. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-14 Branched report: 20101026 changes
Jesse Keating píše v Út 26. 10. 2010 v 12:18 -0700: > On 10/26/10 12:15 PM, Dan Horák wrote: > > Jesse Keating píše v Út 26. 10. 2010 v 12:01 -0700: > >> On 10/26/10 11:46 AM, Branched Report wrote: > >>> Updated Packages: > >>> > >>> tryton-1.6.1-1.fc14 > >>> --- > >>> * Tue Jul 27 2010 Dan Horák 1.6.1-1 > >>> - update to upstream version 1.6.1 > >>> > >>> * Thu Jul 22 2010 Dan Horák 1.6.0-3.1 > >>> - don't build docs on EL <= 5 > >> > >> This is not necessarily a freeze break, but fixing a tagging issue with > >> bodhi. > > > > And there was really some bad timing before the F-14 branching and > > cvs->git conversion because it was built with python 2.6 causing broken > > deps, new build is queued right now. > > > > > > Dan > > > > > > Is the build previous to the one that just showed up functional? If so, > I can make the F14 Everything repo using that package, and your new one > that you're building can be an update. yes, tryton-1.6.0-3.fc14 is ok, so please tag it for GA and I will submit the 1.6.1 as update Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Plan for tomorrow's FESCo meeting (2010-10-26) NEW TIME!
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 18:30UTC (2:30pm EDT) in #fedora-meeting on irc.freenode.net. = Followups = #topic Updates policy #351 Create a policy for updates - status report on implementation https://fedorahosted.org/fesco/ticket/351 #382 Implementing Stable Release Vision https://fedorahosted.org/fesco/ticket/382 * Need work on stats to see trends with new policy. * Need to investigate a 'new features' repo setup. * Need to look at enforcement = New business = #416 Set EOL Date For Fedora 12 https://fedorahosted.org/fesco/ticket/416 * Since F14 was pushed out a week, should we move EOL for F12 as well? Elections coming up. * Note that FESCo (and FAMSCo and Board) elections are coming up. = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-CGI-PSGI] Update to 0.12
commit 7023c15d7586833e431cb2c6ab6535832b2c1a5b
Author: Emmanuel Seyman
Date: Tue Oct 26 21:22:29 2010 +0200
Update to 0.12
.gitignore |1 +
perl-CGI-PSGI.spec |5 -
sources|2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 9ad601f..e8cfb73 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
CGI-PSGI-0.11.tar.gz
+/CGI-PSGI-0.12.tar.gz
diff --git a/perl-CGI-PSGI.spec b/perl-CGI-PSGI.spec
index 3d96ed2..1b5fe50 100644
--- a/perl-CGI-PSGI.spec
+++ b/perl-CGI-PSGI.spec
@@ -1,5 +1,5 @@
Name: perl-CGI-PSGI
-Version:0.11
+Version:0.12
Release:1%{?dist}
Summary:Enable your CGI.pm aware applications to adapt PSGI protocol
License:GPL+ or Artistic
@@ -54,6 +54,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Oct 26 2010 Emmanuel Seyman - 0.12-1
+- Update to 0.12.
+
* Sun May 02 2010 Emmanuel Seyman - 0.11-1
- Update to 0.11.
diff --git a/sources b/sources
index 72edd68..0070656 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-8ed25e9209c7e1d929343313f1a4149f CGI-PSGI-0.11.tar.gz
+77d944c8eae1d1f021b1e46da43643d5 CGI-PSGI-0.12.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On 10/26/2010 04:07 AM, nodata wrote: > Imagine that you want to login to the computer, your username is oiang. > I want to login too. My username is nodata. Now, I can only login to my > account and look at my files because only I know my password. You can > only login to your account because only you know your password. > > Now imagine if you could read all of _my_ files and I could read all of > yours. That makes no sense. You _can_ configure that if you want, but by > default we go for security. > > This is the same. You connect your encrypted hard disk to the system and > you can look at the files on it because you know the passphrase. > > The fix to make this work is a 750 mode on /media/VOLUME-NAME Just to clarify, your encrypted disk is external? Like a USB or eSATA drive? Also I'm curious, if you plugged in a USB thumbdrive (without encryption) does it not allow everyone (with permissions) to view ? I'm not disagreeing with you regarding your use case, just trying to understand it better -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-14 Branched report: 20101026 changes
On 10/26/10 12:15 PM, Dan Horák wrote: > Jesse Keating píše v Út 26. 10. 2010 v 12:01 -0700: >> On 10/26/10 11:46 AM, Branched Report wrote: >>> Updated Packages: >>> >>> tryton-1.6.1-1.fc14 >>> --- >>> * Tue Jul 27 2010 Dan Horák 1.6.1-1 >>> - update to upstream version 1.6.1 >>> >>> * Thu Jul 22 2010 Dan Horák 1.6.0-3.1 >>> - don't build docs on EL <= 5 >> >> This is not necessarily a freeze break, but fixing a tagging issue with >> bodhi. > > And there was really some bad timing before the F-14 branching and > cvs->git conversion because it was built with python 2.6 causing broken > deps, new build is queued right now. > > > Dan > > Is the build previous to the one that just showed up functional? If so, I can make the F14 Everything repo using that package, and your new one that you're building can be an update. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On 10/26/2010 01:03 PM, Gregory Maxwell wrote: > I think that a small change in the default mount behavior so that the > mountpoint encrypted is always owned by the user and mode 700— or if > it were mounted under the user's home directory, perhaps with a > checkbox (defaulting to off) on the password dialog "Make this volume > available to all users on my system", would better meet the user's > expectations of how an encrypted volume should behave. Just out of curiosity... when are these being mounted? If we are talking about mounting a partition from a user session that's one thing and can easily make it user only accessible with a checkbox I guess. I'm wondering though, when you plug in a USB thumbdrive... don't all users have access? What's the difference here? Are we talking about system wide mounts like mine where only /home is encrypted?? Just wondering. -- Nathanael d. Noblet -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File CGI-PSGI-0.12.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-CGI-PSGI: 77d944c8eae1d1f021b1e46da43643d5 CGI-PSGI-0.12.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F-14 Branched report: 20101026 changes
Jesse Keating píše v Út 26. 10. 2010 v 12:01 -0700: > On 10/26/10 11:46 AM, Branched Report wrote: > > Updated Packages: > > > > tryton-1.6.1-1.fc14 > > --- > > * Tue Jul 27 2010 Dan Horák 1.6.1-1 > > - update to upstream version 1.6.1 > > > > * Thu Jul 22 2010 Dan Horák 1.6.0-3.1 > > - don't build docs on EL <= 5 > > This is not necessarily a freeze break, but fixing a tagging issue with > bodhi. And there was really some bad timing before the F-14 branching and cvs->git conversion because it was built with python 2.6 causing broken deps, new build is queued right now. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 646968] New: perl-Syntax-Highlight-Perl6-0.88 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Syntax-Highlight-Perl6-0.88 is available https://bugzilla.redhat.com/show_bug.cgi?id=646968 Summary: perl-Syntax-Highlight-Perl6-0.88 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: ASSIGNED Keywords: FutureFeature, Triaged Severity: medium Priority: low Component: perl-Syntax-Highlight-Perl6 AssignedTo: mmasl...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora Latest upstream release: 0.88 Current version in Fedora Rawhide: 0.87 URL: http://search.cpan.org/dist/Syntax-Highlight-Perl6/ Please consult the package update guidelines before you issue an update to a stable branch: https://fedoraproject.org/wiki/Package_update_guidelines More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_Release_Monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 646966] New: perl-PPIx-Regexp-0.015 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-PPIx-Regexp-0.015 is available https://bugzilla.redhat.com/show_bug.cgi?id=646966 Summary: perl-PPIx-Regexp-0.015 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: ASSIGNED Keywords: FutureFeature, Triaged Severity: medium Priority: low Component: perl-PPIx-Regexp AssignedTo: ppi...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com, ppi...@redhat.com Classification: Fedora Latest upstream release: 0.015 Current version in Fedora Rawhide: 0.014 URL: http://search.cpan.org/dist/PPIx-Regexp/ Please consult the package update guidelines before you issue an update to a stable branch: https://fedoraproject.org/wiki/Package_update_guidelines More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_Release_Monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 596103] perl-Net-Patricia-1.18 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=596103 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Net-Patricia-1.17_03 |perl-Net-Patricia-1.18 is |is available|available --- Comment #1 from Upstream Release Monitoring 2010-10-26 15:03:54 EDT --- Latest upstream release: 1.18 Current version in Fedora Rawhide: 1.17_01 URL: http://search.cpan.org/dist/Net-Patricia/ Please consult the package update guidelines before you issue an update to a stable branch: https://fedoraproject.org/wiki/Package_update_guidelines More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_Release_Monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On Tue, Oct 26, 2010 at 2:18 PM, Przemek Klosowski wrote: > The security role and rationale for the filesystem encryption is to > prevent the access to lost or stolen media, when you can't rely on the > mechanisms existent within the OS. The underlying device encryption > technology is not set up to keep track of who is accessing the data > after it is decrypted and made available to the system, as you correctly > point out. > > Such user-differentiated authorization is provided by the filesystem > access rights, ACLs and SELinux attributes. Note that unlike the first > two mechanisms, SELinux can protect the data even for systems with > compromised root---as someone said, SELinux can be configured so that > you can tell people "here's the root password; now break into my computer". > > What you are asking for improves security by adding additional depth, > but it requires a fairly intensive redesign and reimplementation of the > device encryption, so it befall on you to provide a good analysis and > justification of the tradeoffs. I don't think anyone here is asking for protection from root or anything as elaborate as a SELinux MLS configuration. I think that a small change in the default mount behavior so that the mountpoint encrypted is always owned by the user and mode 700— or if it were mounted under the user's home directory, perhaps with a checkbox (defaulting to off) on the password dialog "Make this volume available to all users on my system", would better meet the user's expectations of how an encrypted volume should behave. There are a lot of neat security things which could and should be done. Why can firefox upload my ssh private key file to random websites? Etc. But this case isn't one of those SELinux rocket science cases, it's simply a matter of using regular unix security in a way that reduces surprises. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 646963] New: perl-Date-Manip-6.14 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Date-Manip-6.14 is available https://bugzilla.redhat.com/show_bug.cgi?id=646963 Summary: perl-Date-Manip-6.14 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: ASSIGNED Keywords: FutureFeature, Triaged Severity: medium Priority: low Component: perl-Date-Manip AssignedTo: mmasl...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora Latest upstream release: 6.14 Current version in Fedora Rawhide: 6.13 URL: http://search.cpan.org/dist/Date-Manip/ Please consult the package update guidelines before you issue an update to a stable branch: https://fedoraproject.org/wiki/Package_update_guidelines More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_Release_Monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 646962] New: perl-CPAN-Checksums-2.06 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-CPAN-Checksums-2.06 is available https://bugzilla.redhat.com/show_bug.cgi?id=646962 Summary: perl-CPAN-Checksums-2.06 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: ASSIGNED Keywords: FutureFeature, Triaged Severity: medium Priority: low Component: perl-CPAN-Checksums AssignedTo: mmasl...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora Latest upstream release: 2.06 Current version in Fedora Rawhide: 2.05 URL: http://search.cpan.org/dist/CPAN-Checksums/ Please consult the package update guidelines before you issue an update to a stable branch: https://fedoraproject.org/wiki/Package_update_guidelines More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_Release_Monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F-14 Branched report: 20101026 changes
On 10/26/10 11:46 AM, Branched Report wrote: > Updated Packages: > > tryton-1.6.1-1.fc14 > --- > * Tue Jul 27 2010 Dan Horák 1.6.1-1 > - update to upstream version 1.6.1 > > * Thu Jul 22 2010 Dan Horák 1.6.0-3.1 > - don't build docs on EL <= 5 This is not necessarily a freeze break, but fixing a tagging issue with bodhi. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-14 Branched report: 20101026 changes
Compose started at Tue Oct 26 16:34:49 UTC 2010 Broken deps for x86_64 -- qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) tryton-1.6.1-1.fc14.noarch requires python(abi) = 0:2.6 Broken deps for i386 -- qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18 tryton-1.6.1-1.fc14.noarch requires python(abi) = 0:2.6 Removed package: rakudo-0.0.2010.08_2.7.0-1.fc14 Updated Packages: tryton-1.6.1-1.fc14 --- * Tue Jul 27 2010 Dan Horák 1.6.1-1 - update to upstream version 1.6.1 * Thu Jul 22 2010 Dan Horák 1.6.0-3.1 - don't build docs on EL <= 5 Summary: Added Packages: 0 Removed Packages: 1 Modified Packages: 1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HEADS UP: KDE/Qt update intentions in Fedora 13 (RFC)
Peter Robinson (pbrobin...@gmail.com) said: > > Nokia managed to upgrade Qt to 4.7 in their Maemo distribution and it got > > pushed to all devices without causing any problems so far. Their standards > > for > > avoiding churn are pretty high and their update scheme is extremely > > conservative for stable releases. Nevertheless they updated Qt. But they > > have > > a pretty good reason for doing that (aligning with future versions of MeeGo > > and Symbian). So what does a F13 user gain from an upgrade? Is it worth the > > risks? > > QT isn't the default toolkit in Maemo and it was only introduced at > all in the PR1.2 release which only came out around 3-4 months ago so > its not a core part of their UI experience on maemo. > > So that's not really a good argument for upgrading it in F-13. Also, I'd assume that Maemo explictily ships/supports a much smaller set of software than Fedora, so they can explicitly list all their dependencies that may need fixed. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HEADS UP: KDE/Qt update intentions in Fedora 13 (RFC)
On Tue, Oct 26, 2010 at 6:01 PM, Lars Seipel wrote: > On Sunday 24 October 2010 20:24:30 Kalev Lember wrote: >> KDE is pretty much self contained, whereas a Qt upgrade affects a much >> larger number of packages. I don't think updating Qt to a new major >> version in a stable Fedora release is a good idea; it just causes too >> much churn. > > Nokia managed to upgrade Qt to 4.7 in their Maemo distribution and it got > pushed to all devices without causing any problems so far. Their standards for > avoiding churn are pretty high and their update scheme is extremely > conservative for stable releases. Nevertheless they updated Qt. But they have > a pretty good reason for doing that (aligning with future versions of MeeGo > and Symbian). So what does a F13 user gain from an upgrade? Is it worth the > risks? QT isn't the default toolkit in Maemo and it was only introduced at all in the PR1.2 release which only came out around 3-4 months ago so its not a core part of their UI experience on maemo. So that's not really a good argument for upgrading it in F-13. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On 10/25/2010 06:40 PM, nodata wrote: > On 26/10/10 00:31, Nathanael D. Noblet wrote: >> On 10/25/2010 04:28 PM, nodata wrote: >>> Hi, >>> >>> I'm concerned about the default behaviour of mounting encrypted volumes. >>> >>> The default behaviour is that a user must know and supply a passphrase >>> in order to mount an encrypted volume. This is good: know the >>> passphrase, you get to mount the volume. >>> >>> What I am concerned about is that the volume is mounted for _every_ user >>> on the system to see. >>> The security role and rationale for the filesystem encryption is to prevent the access to lost or stolen media, when you can't rely on the mechanisms existent within the OS. The underlying device encryption technology is not set up to keep track of who is accessing the data after it is decrypted and made available to the system, as you correctly point out. Such user-differentiated authorization is provided by the filesystem access rights, ACLs and SELinux attributes. Note that unlike the first two mechanisms, SELinux can protect the data even for systems with compromised root---as someone said, SELinux can be configured so that you can tell people "here's the root password; now break into my computer". What you are asking for improves security by adding additional depth, but it requires a fairly intensive redesign and reimplementation of the device encryption, so it befall on you to provide a good analysis and justification of the tradeoffs. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HEADS UP: KDE/Qt update intentions in Fedora 13 (RFC)
On Sunday 24 October 2010 20:24:30 Kalev Lember wrote: > KDE is pretty much self contained, whereas a Qt upgrade affects a much > larger number of packages. I don't think updating Qt to a new major > version in a stable Fedora release is a good idea; it just causes too > much churn. Nokia managed to upgrade Qt to 4.7 in their Maemo distribution and it got pushed to all devices without causing any problems so far. Their standards for avoiding churn are pretty high and their update scheme is extremely conservative for stable releases. Nevertheless they updated Qt. But they have a pretty good reason for doing that (aligning with future versions of MeeGo and Symbian). So what does a F13 user gain from an upgrade? Is it worth the risks? F13 isn't what bleeding-edge users are likely to run in the future. Those can easily upgrade to F14 and enjoy the latest stuff. So it's not like they are forced to run a periodical broken rawhide with no security support if they want recent software. I like the idea of Fn getting major updates whereas Fn-1 (that's what F13 is very soon) only gets those updates which are needed for fixing bugs and security issues. So if the open issues regarding QtWebkit can be solved I agree that leaving Qt at 4.6.x is just fine. If not there ain't much choice as it is pretty much guaranteed that Webkit will have security issues which are mandatory to fix. If upstream only supports 4.7 and backporting isn't an option (which seems to be the case according to jreznik) Qt 4.6 has to go unless some other solution can be implemented before F13 goes EOL. ;) Lars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On 10/26/2010 05:14 PM, Vaclav Mocek wrote: > On 10/26/2010 03:57 PM, nodata wrote: >> On 26/10/10 16:11, Andrew Haley wrote: >> >>> On 10/26/2010 02:44 PM, Matthew Garrett wrote: >>> On Tue, Oct 26, 2010 at 12:28:55AM +0200, nodata wrote: > What I am concerned about is that the volume is mounted for _every_ user > on the system to see. > Only if the permissions are set that way. chmod 0750 /whatever and it won't be. >>> On my system an auto-mounted exchangeable volume always seems to be 0700. >>> >> Really? Any chance of a copy-paste? >> >> This is what I get: >> >> $ ls -la /media/ >> total 12 >> drwxr-xr-x. 3 root root 4096 Oct 26 16:51 . >> dr-xr-xr-x. 24 root root 4096 Oct 26 16:51 .. >> drwxr-xr-x. 4 root root 4096 Oct 23 17:40 WESTERNDIGITAL >> >> > Exactly. It is 0755. $ ls -la /media total 16 drwxr-xr-x. 3 root root 4096 2010-10-26 17:56 ./ dr-xr-xr-x. 28 root root 4096 2010-09-16 04:24 ../ drwx--. 2 aph aph 8192 1970-01-01 01:00 C0C1-215C/ Ahh, I think I may know why: it's a DOS filesystem. Sorry for the noise. And yes, I agree. 0755 makes no sense to me. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On 10/26/2010 03:57 PM, nodata wrote: > On 26/10/10 16:11, Andrew Haley wrote: > >> On 10/26/2010 02:44 PM, Matthew Garrett wrote: >> >>> On Tue, Oct 26, 2010 at 12:28:55AM +0200, nodata wrote: >>> >>> What I am concerned about is that the volume is mounted for _every_ user on the system to see. >>> Only if the permissions are set that way. chmod 0750 /whatever and it >>> won't be. >>> >> On my system an auto-mounted exchangeable volume always seems to be 0700. >> >> Andrew. >> > Really? Any chance of a copy-paste? > > This is what I get: > > $ ls -la /media/ > total 12 > drwxr-xr-x. 3 root root 4096 Oct 26 16:51 . > dr-xr-xr-x. 24 root root 4096 Oct 26 16:51 .. > drwxr-xr-x. 4 root root 4096 Oct 23 17:40 WESTERNDIGITAL > > Exactly. It is 0755. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On Tue, Oct 26, 2010 at 16:56:41 +0200, nodata wrote: > On 26/10/10 16:00, Bruno Wolff III wrote: > > On Tue, Oct 26, 2010 at 12:07:56 +0200, > >nodata wrote: > >> > >> Now imagine if you could read all of _my_ files and I could read all of > >> yours. That makes no sense. You _can_ configure that if you want, but by > >> default we go for security. > > > > Once upon a time that was the default for systems. > > > >> This is the same. You connect your encrypted hard disk to the system and > >> you can look at the files on it because you know the passphrase. > > > > That is muddy thinking. The OS needs the password, you can't directly look > > at the disk using the password in your head. The OS needs to manage access > > to the encrypted device. > > I don't really understand what you're trying to say here. > > A person who knows the passphrase and nobody else (apart from super > users, the kernel, etc) should be the only one who can access the > unencrypted device. How do you expect this to happen? The user is going to supply the password to the OS and it is going to access the volume. At that point the OS is protecting the data from unauthorized use by other users, not a password. So you need to use normal OS controls on this. The feature you seem to be looking for is that when an encrypted device is mounted, that there be different defaults than when automounting unencrypted devices. That might be reasonable (depending on what the defaults are). If the device has an ext* file system on it, normal uid usage should be good enough if you just use it on one system or accross a set where you have the same uid. You can also use /etc/fstab to automatically control how the device is mounted. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xz-5.0.0 in rawhide + soname bump
On Tue, Oct 26, 2010 at 07:36:47AM -0700, Toshio Kuratomi wrote: > On Tue, Oct 26, 2010 at 11:02:41AM +0200, Jindrich Novy wrote: > > The new xz-5.0.0-3 with a new xz-compat-libs subpackage containing > > liblzma.so.0* libraries is just built. This should solve the chicken > > and egg problem with rpm and elfutils as the old library will still be > > available in the repository. > Note: > > If this is intended to be a long term compat package then we probably want > a new review for the package instead of shipping xz with two tarballs. If > this is just intended to get us out of the chicken and egg situation with > rpm (This sounds like the better approach to me) then we should make sure > rpm and elfutils are rebuilt asap and then drop the compat packages. > > -Toshio Yes, this is just a temporary solution which assures that upgrade to the new xz is actually possible. The plan is that the xz-compat-libs will be dropped at some point and packaged separately (if there is a need to, i.e. some package requires it). In the meantime rebuild of all xz dependencies is recommended. Note for devels/packagers depending on xz: The new library liblzma.so.5 in the new xz is mostly API/ABI compatible with old liblzma.so.0 so you shouldn't need to touch source code using xz, i.e. rebuild is safe. If you experience any problems or unsure, feel free to mail me directly. Cheers, Jindrich -- Jindrich Novyhttp://people.redhat.com/jnovy/ Kdo víno má a nepije, kdo hrozny má a nejí je, kdo ženu má a nelíbá, kdo zábavě se vyhýbá, na toho vemte bič a hůl, to není člověk, to je vůl. --- Jan Werich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i686/x86_64 dual install media
On Sun, 24 Oct 2010 10:45:38 -0400, Mark Bidewell wrote: > Sorry if this has been discussed, but has there every been discussion > of a dual 32/64-bit install media? /usr/bin/mkbiarch is included in livecd-tools-034-2.fc14 upwards: http://koji.fedoraproject.org/koji/fileinfo?rpmID=2167124&filename=/usr/bin/mkbiarch It was too late for an official biarch spin of F14 but it should hopefully be available on F15 GA. Regards, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Net-SNMP soname bump in rawhide
I have just rebased Net-SNMP to 5.6 in rawhide. The update includes new soname for all libraries and following packages need to be recompiled: 389-ds-base amavisd-new apcupsd asterisk cacti cluster-glue clustermon collectd cpqarrayd hplip ifstat mon nagios-plugins-snmp-disk-proc netdisco ntop nut openhpi openhpi-subagent OpenIPMI openscada openser opensips pacemaker perl-SNMP-Info php pynetsnmp pysnmp quagga tog-pegasus zabbix Please contact me if something goes wrong, IMO the API is backward compatible and everything should be just fine. Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On 26/10/10 16:11, Andrew Haley wrote: > On 10/26/2010 02:44 PM, Matthew Garrett wrote: >> On Tue, Oct 26, 2010 at 12:28:55AM +0200, nodata wrote: >> >>> What I am concerned about is that the volume is mounted for _every_ user >>> on the system to see. >> >> Only if the permissions are set that way. chmod 0750 /whatever and it >> won't be. > > On my system an auto-mounted exchangeable volume always seems to be 0700. > > Andrew. Really? Any chance of a copy-paste? This is what I get: $ ls -la /media/ total 12 drwxr-xr-x. 3 root root 4096 Oct 26 16:51 . dr-xr-xr-x. 24 root root 4096 Oct 26 16:51 .. drwxr-xr-x. 4 root root 4096 Oct 23 17:40 WESTERNDIGITAL -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On 26/10/10 16:00, Bruno Wolff III wrote: > On Tue, Oct 26, 2010 at 12:07:56 +0200, >nodata wrote: >> >> Now imagine if you could read all of _my_ files and I could read all of >> yours. That makes no sense. You _can_ configure that if you want, but by >> default we go for security. > > Once upon a time that was the default for systems. > >> This is the same. You connect your encrypted hard disk to the system and >> you can look at the files on it because you know the passphrase. > > That is muddy thinking. The OS needs the password, you can't directly look > at the disk using the password in your head. The OS needs to manage access > to the encrypted device. I don't really understand what you're trying to say here. A person who knows the passphrase and nobody else (apart from super users, the kernel, etc) should be the only one who can access the unencrypted device. > >> The fix to make this work is a 750 mode on /media/VOLUME-NAME > > I'd surely suggest using 0700 instead of 0750 given your concerns about > other people being able to access the contents. > > Using selinux provides a way to limit accidental leaking in some circumstances > and may be a better approach if you have time to do the upfront work. > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On Tue, Oct 26, 2010 at 12:28:55AM +0200, nodata wrote:
> The default behaviour is that a user must know and supply a passphrase
> in order to mount an encrypted volume. This is good: know the
> passphrase, you get to mount the volume.
>
> What I am concerned about is that the volume is mounted for _every_ user
> on the system to see.
Another option is guestfish which has LUKS support now (in Fedora 14).
This works because guestfish runs another Linux kernel as the local
user, and you only pass the key to that kernel. The normal user
separation of Linux prevents another non-root user from gaining access
to the key.
As with all of the schemes discussed, root on the machine would still
be able to gain access. Local non-root users could also try their
hand at exploiting the host kernel -- usually easier to do than a
remote exploit -- or looking for some side channel such as keys being
leaked through process arguments. Local users + super-secret data is
not a great recipe for assured security.
Rich.
$ guestfish --ro -a F13x64Encrypted.img
Welcome to guestfish, the libguestfs filesystem interactive shell for
editing virtual machine filesystems.
Type: 'help' for a list of commands
'man' to read the manual
'quit' to quit the shell
> run
> list-partitions
/dev/vda1
/dev/vda2
> luks-open /dev/sda2 encrypted
Enter key or passphrase ("key"):
> vgscan
> vg-activate true ""
> lvs
/dev/vg_f13x64encrypted/lv_root
/dev/vg_f13x64encrypted/lv_swap
> mount-options "" /dev/vg_f13x64encrypted/lv_root /
> ll /home/
total 12
drwxr-xr-x. 3 root root 4096 Jul 21 12:00 .
dr-xr-xr-x. 24 root root 4096 Jul 21 12:01 ..
drwx--. 4 500 500 4096 Jul 21 12:00 rjones
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xz-5.0.0 in rawhide + soname bump
On Tue, Oct 26, 2010 at 11:02:41AM +0200, Jindrich Novy wrote: > On Mon, Oct 25, 2010 at 12:59:22PM -0600, Kevin Fenzi wrote: > > > The current build needs untagging anyway. > > > > I've untagged it and mailed Jindrich. > > > > Updating a rpm dep is not easy. You will need to rebuild rpm static, or > > make a compat package, or some other trick. ;) > > > > The new xz-5.0.0-3 with a new xz-compat-libs subpackage containing > liblzma.so.0* libraries is just built. This should solve the chicken > and egg problem with rpm and elfutils as the old library will still be > available in the repository. > > The liblzma.so.0 is built from the old xz 4.999.9beta so it should > serve to apps requiring old compression settings well. > Note: If this is intended to be a long term compat package then we probably want a new review for the package instead of shipping xz with two tarballs. If this is just intended to get us out of the chicken and egg situation with rpm (This sounds like the better approach to me) then we should make sure rpm and elfutils are rebuilt asap and then drop the compat packages. -Toshio pgpJvMmLmJF2j.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
mono-ndoc
Hi, With the dropping of .NET 1.1 support in mono-2.8, mono-ndoc will now no longer compile (there is very little support for .NET 2.0 in it anyway). It's dead in the water. The original author has said he no longer wishes to maintain the package. I'm not sure what actually depends on mono-ndoc, so it may not be that big a problem. It will though need to be removed from rawhide - how is this done? log4net may also be on its way out too... TTFN Paul -- Vertraue mir, ich weiss, was ich mache... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On 10/26/2010 02:44 PM, Matthew Garrett wrote: > On Tue, Oct 26, 2010 at 12:28:55AM +0200, nodata wrote: > >> What I am concerned about is that the volume is mounted for _every_ user >> on the system to see. > > Only if the permissions are set that way. chmod 0750 /whatever and it > won't be. On my system an auto-mounted exchangeable volume always seems to be 0700. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On Tue, Oct 26, 2010 at 12:07:56 +0200, nodata wrote: > > Now imagine if you could read all of _my_ files and I could read all of > yours. That makes no sense. You _can_ configure that if you want, but by > default we go for security. Once upon a time that was the default for systems. > This is the same. You connect your encrypted hard disk to the system and > you can look at the files on it because you know the passphrase. That is muddy thinking. The OS needs the password, you can't directly look at the disk using the password in your head. The OS needs to manage access to the encrypted device. > The fix to make this work is a 750 mode on /media/VOLUME-NAME I'd surely suggest using 0700 instead of 0750 given your concerns about other people being able to access the contents. Using selinux provides a way to limit accidental leaking in some circumstances and may be a better approach if you have time to do the upfront work. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On 10/26/2010 09:44 AM, Matthew Garrett wrote: > On Tue, Oct 26, 2010 at 12:28:55AM +0200, nodata wrote: > >> What I am concerned about is that the volume is mounted for _every_ user >> on the system to see. > Only if the permissions are set that way. chmod 0750 /whatever and it > won't be. > I think that the concern is correct and valid - using encrypted block devices with a mount time password is quite "weak" for system security in general, it is just the easiest way to provide basic crypto. Much better suited for laptops than servers where any root user would be able to peruse the mounted volume's contents. There are a host of other ways to do this though - ecryptfs (as Eric Sandeen mentioned) does finer grained crypto (even though we are not huge fans of how its design) and you can certainly encrypt files individually. Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On Tue, Oct 26, 2010 at 12:28:55AM +0200, nodata wrote: > What I am concerned about is that the volume is mounted for _every_ user > on the system to see. Only if the permissions are set that way. chmod 0750 /whatever and it won't be. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 646832] New: Net::Amazon::S3 is way out of date, please update
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Net::Amazon::S3 is way out of date, please update https://bugzilla.redhat.com/show_bug.cgi?id=646832 Summary: Net::Amazon::S3 is way out of date, please update Product: Fedora Version: 14 Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: medium Priority: low Component: perl-Net-Amazon-S3 AssignedTo: rr...@redhat.com ReportedBy: j...@kamens.brookline.ma.us QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, rr...@redhat.com Classification: Fedora perl-Net-Amazon-S3 is currently version 0.43, which is very old. Current version is 0.53. Please update. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/26/2010 02:36 AM, Tomas Mraz wrote: > On Tue, 2010-10-26 at 00:28 +0200, nodata wrote: >> Hi, >> >> I'm concerned about the default behaviour of mounting encrypted volumes. >> >> The default behaviour is that a user must know and supply a passphrase >> in order to mount an encrypted volume. This is good: know the >> passphrase, you get to mount the volume. >> >> What I am concerned about is that the volume is mounted for _every_ user >> on the system to see. >> >> I've filed a bug about this, and it got closed: >> https://bugzilla.redhat.com/show_bug.cgi?id=646085 >> >> I'm quite in favour of secure by default. In the worst case, the >> mountpoint would have permissions set to read access to all if you tick >> a box. >> >> Thoughts? >> > > This could be achieved by using pam_namespace to separate the namespaces > of the logged-in users and mounting the encrypted volume as private into > the namespace. However it also means that when the user is > simultaneously logged in twice, he will not be able to access the > encrypted volume in the second session either. It also means that the > process that mounts the volume must run in the namespace of the user's > session (setuid helper would be needed instead of using system service > to mount the volume). > Might be something we could add to seunshare? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzGx7QACgkQrlYvE4MpobNHaACgrpZOOlI7IRtgPFEImpQnNZBs SNsAnRjAIRe9TJCg8NbA9hHOMcxrjiLr =Kwo5 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On 26/10/10 07:05, Qiang Li wrote: > On Tue, 2010-10-26 at 00:28 +0200, nodata wrote: >> Hi, >> >> I'm concerned about the default behaviour of mounting encrypted volumes. >> >> The default behaviour is that a user must know and supply a passphrase >> in order to mount an encrypted volume. This is good: know the >> passphrase, you get to mount the volume. >> >> What I am concerned about is that the volume is mounted for _every_ user >> on the system to see. >> >> I've filed a bug about this, and it got closed: >>https://bugzilla.redhat.com/show_bug.cgi?id=646085 >> >> I'm quite in favour of secure by default. In the worst case, the >> mountpoint would have permissions set to read access to all if you tick >> a box. >> >> Thoughts? >> > > I'd think you mixed the concept of volume encryption and permission. > Once you supply the pass for the encrypted volume, it means that you > grant the right to OS to mount this volume. Then the OS is in charge of > permission settings. OS doesn't care about if it is encrypted or not, it > only knows some volume wants to be mounted and it sets permission as the > default schema. > > Qiang > Imagine that you want to login to the computer, your username is oiang. I want to login too. My username is nodata. Now, I can only login to my account and look at my files because only I know my password. You can only login to your account because only you know your password. Now imagine if you could read all of _my_ files and I could read all of yours. That makes no sense. You _can_ configure that if you want, but by default we go for security. This is the same. You connect your encrypted hard disk to the system and you can look at the files on it because you know the passphrase. The fix to make this work is a 750 mode on /media/VOLUME-NAME -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 14 Final RC1 Recap
Greetings, As you can see in the bug list summarized below, Test results of F-14-Final-RC1 are positive so far, no blocker bugs were found when executing the tests. Many thanks for the hard working of developers, rel-engineers, and testers to keep improve the quality of Fedora. = Installation === * F14-accepted: 645645 NEW - Another grub picture is shown before the regular one 646437 MODIFIED - Fail to login to desktop after preupgrading to F14 from F12 * Warnings: 585006 NEW - anaconda and livecd-creator are creating i386 and x86_64 ISOs which are larger than indicated by the ISO header 645660 CLOSED DUPLICATE 645606 - F14 Final RC1 Live does not show gnome background === Desktop = * Warnings: 646041 NEW - Missing "OK" button 643435 NEW - Automatically unlock function seems break. It always asks password when I'm logged in. For detailed test results, please refer to: https://fedoraproject.org/wiki/Category:Fedora_14_Final_RC_Test_Results Also be noticed that Fedora 14 FINAL Go/No-Go Meeting will be held soon today at 21:00 UTC. Stay tuned for this. Many Thanks! Hurry -- Contacts Hurry FAS Name: Rhe Timezone: UTC+8 TEL: 86-010-62608141 IRC nick: rhe #fedora-qa #fedora-zh ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xz-5.0.0 in rawhide + soname bump
On Mon, Oct 25, 2010 at 12:59:22PM -0600, Kevin Fenzi wrote: > > The current build needs untagging anyway. > > I've untagged it and mailed Jindrich. > > Updating a rpm dep is not easy. You will need to rebuild rpm static, or > make a compat package, or some other trick. ;) > The new xz-5.0.0-3 with a new xz-compat-libs subpackage containing liblzma.so.0* libraries is just built. This should solve the chicken and egg problem with rpm and elfutils as the old library will still be available in the repository. The liblzma.so.0 is built from the old xz 4.999.9beta so it should serve to apps requiring old compression settings well. Thanks for patience, Jindrich -- Jindrich Novyhttp://people.redhat.com/jnovy/ Kdo víno má a nepije, kdo hrozny má a nejí je, kdo ženu má a nelíbá, kdo zábavě se vyhýbá, na toho vemte bič a hůl, to není člověk, to je vůl. --- Jan Werich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: policycoreutils needs cairo.
On 10/26/2010 04:22 AM, Adam Williamson wrote: > > Having said that, I don't think this seems serious enough to be a > blocker, though obviously we'd like the minimal install to be as minimal > as possible. Does it cause major problems for any spins? I doubt it, I > expect most of them will have cairo for one reason or another anyway. Can we make this such issues a blocker starting from the next release? A minimal install should really be minimal. Otherwise, we have failed and it does affect EC2 deployments among other things. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
