Re: Promoting i386 version over x86_64?

[drago01]

On Thu, Nov 19, 2009 at 2:56 AM, Kevin Kofler  wrote:
> King InuYasha wrote:
>> In any case, 32-bit shouldn't be considered legacy until every type of
>> computer sold is 64-bit. And the fact is, that isn't true.
>
> It already basically was before netbooks came and turned the clock back. :-(
>
>> Netbooks are entirely 32-bit currently
>
> Yeah, they're a huge step backwards (and not just for 64-bit computing, but
> also for CPU speed, RAM, disk space (especially where SSDs are used instead
> of the traditional HDDs)

If you ever used an SSD you wouldn't call it a step backwards, it is
so much better than a traditional HD that I don't want a Laptop
without one ever again.
HDDs should be the ones of the past, but for that prices need to drop.

Anyway offtopic here.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)

[Jeff Garzik]

On 11/18/2009 09:56 PM, Roland McGrath wrote:

Another data point for this thread:


x86 is unlike other architectures because 64-bit also has twice as many
registers as 32-bit.  So you get to trade off the benefits of register
allocation across more registers against the memory/cache footprint of
64-bit pointers.


Absolutely.  x86-64 is definitely one of my favorite ISAs.  Worlds 
improvement from i386.


Jeff


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Jeff Garzik]

On 11/18/2009 11:27 PM, Adam Williamson wrote:

On Wed, 2009-11-18 at 20:20 -0600, Mike McGrath wrote:


5) The people who want this new security policy should add an opt-in checkbox
in Anaconda or firstboot.



Does anyone disagree with anything in 1-5?  It all sounds reasonable to
me?


I disagree with 5, that's not a sensible or sustainable way to deal with
this kind of thing. At least not without some kind of coherent process.
Just throwing in single-issue checkboxes ad hoc is not the way to do
this - should we have fifty checkboxes for everything you can configure
users to be able to do or not able to do? If we're going to go down that
route, it needs to be a properly planned utility, something like
Mandriva's msec. Only, uh, probably better.


Your and Rahul's points are definitely well taken.  Certainly quite a 
few know quite a bit more than I do, about where to put this "policy knob."


IMO #2 is the only urgent priority -- if this decision will be reverted 
(it should!), it should happen very soon, so that users can capture this 
in updates as soon after install as possible.


Jeff



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

[Ikem Krueger]

>> What do the people with 32bit cpus who won't/can't upgrade?

> Then the Y2k38 problem occurs, which is what the theoretical Y2K problem
> would have been.

No. I meant, what is the solution?

Can't we not just write down the time somewhere and began to count the
time from "zero"? o.O

> Nowadays, it isn't unusual for applications to require at least 512MB of RAM. 
> That builds up, quite quickly.

I have only 512MB RAM and I think it is more then enough! And I don't
plan to upgrade. If the app eats all my memory, I look for an
alternative!

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Keith G. Robertson-Turner]

Verily I say unto thee, that Rahul Sundaram spake thusly:
> On 11/19/2009 11:51 AM, Keith G. Robertson-Turner wrote:
> 
>> Error: Too many assumptions. Stack overflow.
> 
> Yes, you are making too many assumptions

Where?

-- 
Regards,
Keith G. Robertson-Turner

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Keith G. Robertson-Turner]

Verily I say unto thee, that Bill Nottingham spake thusly:
> Jeff Garzik (jgar...@pobox.com) said:
>> Sorry, but this default (desktop users can install pkgs without 
>> root) is just stupid.  It is antithetical to all standard security 
>> models that have come before in Fedora and other Linux 
>> distributions.
> 
> Out of the box, a desktop user has the ability to shut down the
> machine. This gives them the ability, out of the box, to:
> - DoS everyone on it
> - get a root shell
> -- install whatever they want
> -- put viruses on
> - hell, slap in a livecd or USB key and reinstall the box

The desktop users on my network might have difficulty doing any of those
things, since their "desktop" access is via VNC tunnelled through ssh.

However, now it seems they can arbitrarily install software into /usr,
on a server that is (for some of them) in a foreign country, because of
something called PackageKit.

Can you see why I might not like that situation?

> It's a behavior change, for sure.

Yes. It's changed the behaviour of my server from trusted to untrusted.

> For people who want to lock down their systems, it's a default they
> will need to be able to change

In spam terms, that's what they call "opt-out".

I don't like that much either.

> and they should have been able to discover it through the normal
> mechanisms for that. (i.e., the release notes.).

Timely discovery of an unacceptable condition, does not somehow make
that condition any more acceptable.

> OMG THE SKY IS FALLING

It didn't fall.
It was pushed.

> Maybe people are tired of bagging tea and want new things to be
> outraged about.

Yes, maybe complaining about the subversion of 40 years of UNIX security
is being somewhat petty.

-- 
Regards,
Keith G. Robertson-Turner

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Rahul Sundaram]

On 11/19/2009 11:09 AM, Dave Airlie wrote:

> 
> Really all this bullshit in this thread, and not one patch? I think
> ppl prefer hearing themselves spout than actually supply a fix.

What patch should be supplied?  It wasn't a accidental but a deliberate
choice. If that choice is now considered wrong, he can very well revert
it himself. No patch necessary.

Rahul

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Adam Williamson]

On Thu, 2009-11-19 at 15:39 +1000, Dave Airlie wrote:

> Why do you assume anyone here on this thread can fix this?
> 
> Its up to the package maintainer to take a fix and ensure its well
> tested, pointless fire-drill exercises might make you feel better,
> but they don't help the distro.
> 
> Really all this bullshit in this thread, and not one patch? I think
> ppl prefer hearing themselves spout than actually supply a fix.

I don't think it's a question of supplying a patch. It's not a code
deficiency, it's a conscious policy choice. The maintainer knows
perfectly well how to change the policy - after all, that's what he did
in the first place. It's not that he's just waiting on a patch, that's
not the issue here.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Tony Nelson]

On 09-11-18 20:09:18, Bastien Nocera wrote:
> On Wed, 2009-11-18 at 13:50 -0500, Tony Nelson wrote:
 ..
> > Fedora has always been this way.  Have you tried to use sound or
> > video in the past few releases?  I think it's called "creative
> > destruction".
> 
> And I'm sure the passive-aggressive in you filed bugs.

Yes, I did.  Might not have been the passive-aggressive in me, though.  
Don't be smarmy.

-- 

TonyN.:'   
  '  


-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Rahul Sundaram]

On 11/19/2009 11:51 AM, Keith G. Robertson-Turner wrote:

> 
> Error: Too many assumptions. Stack overflow.

Yes, you are making too many assumptions and ranting. Just stop unless
you have something new to say.

Rahul

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Keith G. Robertson-Turner]

Verily I say unto thee, that Rahul Sundaram spake thusly:
> On 11/18/2009 11:27 PM, nodata wrote:
> 
>> Why is it a problem? For all of the reasons that it has never been
>> a problem before. For the reason that the user is not the
>> administrator or the box, for the reason that the user is the user
>> for a reason, for the reason that by default Linux should act like
>> Linux, for the reason that the default is bad,
> 
> All of these seems rather circular.

I don't find "the user is not the administrator" a circular argument.

Perhaps the reason that his arguments seems circular, is that he's
having difficulty with the concept of having to spell-out the
fundamental axioms of computer security ... on a developers list.

Let's try an analogy, and just for maximal irritation let's make it a
car analogy, which I know everyone loves:

You drive your 12 year old son to school every day. In this sense, he is
a user of the car. You fill the tank at the same gas station every day.

Would you give the keys of your car to your 12 year old son, and ask him
to drive to the gas station, simply because your son is an authorised
"user" of your car, and because you trust the quality of the fuel from
that gas station?

Users are not, and should never be, administrators.

The assumption that every Fedora user is also the administrator on a
single-user system, is just that ... an assumption, and one which is
statistically highly unlikely to be universally correct.

Should those administrators of multi-user systems be subjected to this
sort of insecurity by default?

And frankly, even if it were the case that Fedora was being universally
rejected for server operation, I find this new policy an affront to the
basic principles of UNIX security. And if you need further clarification
on that highly impassioned opinion, then let me explain (as if I should
need to do so) why the principle "do not take the name of thy root in
vein" has attained the status of aphorism: If there is no clear
separation of privileged from unprivileged access on a computer system,
then privileged access quickly becomes the norm (a la Microsoft
Windows), and thus every bleary-eyed mistake becomes a potentially fatal
issue for the entire system, every user on that system, and possibly
even further afield (e.g. spam-bots).

One look at the current pitiful state of Windows security should be more
than sufficient explanation for why this new policy is the mother of all
bad ideas.

> Should the defaults be targeted towards home users or corporate
> desktop considering the short lifecycle of Fedora and the target
> audience?

Since when did security become optional in Linux?

Isn't it supposed to be one of the biggest (if not the biggest)
differentiator from Windows?

And are you suggesting that corporate users, or any others in a
multi-user environment, are not supposed to use Fedora?

Are there, in fact, no Fedora users in such an environment? And if there
are, doesn't Fedora have a social responsibility to ensure that
environment is secure be default, or indeed that Fedora in /any/
environment is secure by default?

> I am not sure there are corporate deployments but wouldn't they be
> heavily customized their desktop deployments and kickstarting it
> anyway?

Maybe some are.

Inevitably, some won't be.

Error: Too many assumptions. Stack overflow.

-- 
Regards,
Keith G. Robertson-Turner

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Tom "spot" Callaway]

On 11/18/2009 08:22 PM, Todd Zullinger wrote:
> [At the risk of letting this get lost in the shuffle of this
> thread...]
> 
> Seth Vidal wrote:
>> If there are pkgs which run daemons which are defaulting to ON when
>> installed or on next reboot - then we should be auditing those pkgs.
>> Last I checked we default to OFF and that should continue to be the
>> case.
> 
> I happened to install func the other day on several Fedora and CentOS
> boxes and was surprised that both services defaulted to on.

Please file a bug here.

~spot

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: RPM dependency on cron

[Panu Matilainen]

On Fri, 6 Nov 2009, Benny Amorsen wrote:


We have a lot of virtualized (OpenVZ) Fedora servers. Until now I have
avoided running cron inside each server; log rotation is done from the
host.

This has worked rather well until lately. Unfortunately rpm has acquired
a dependency on crontabs, because it adds a file to /etc/cron.daily. In
turn, crontabs depends on /etc/cron.d, which is provided by cronie.
cronie explicitly depends on anacron. And thus, anacron and cronie are
required for all Fedora installations.

The really nasty thing is that cronie turns itself on when installed! I
suddenly had an extra logrotate running which rotated logs in a way not
consistent with our policy.

I'm not sure where it's easiest to cut this chain. I'd be tempted to
make crontabs provide /etc/cron.d and make cronie depend on crontabs.
That way rpm would pull in crontabs but nothing more.


In Fedra >= 12 the cronjob was split to a separate subpackage to avoid 
this dependency chain on minimal installs: 
https://bugzilla.redhat.com/show_bug.cgi?id=500722


Doing that as F11 update is not really an option though.

- Panu -

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Dave Airlie]

On Wed, 2009-11-18 at 23:24 -0500, Mail Llists wrote:
> Jeff et al are 100% correct - why this is even debated is unfathomable
> to me.
> 
> Surely it is completely obvious that the default should be off. (as it
> was and will be in f13+).
> 
>  Why have we not got a revert fix to turn this back off in updates-testing ?
> 
>  Please fix it now - then discuss how to improve the desktop experiance
> for Aunt tilly. But first put the security back to what it was, should
> be and presumably will be again anyway.
> 
>  If people need it, add a button to the PK gui config tool. (WHat is it
> called anyway?) - I cant seem to find a [gui] config tool of any kind -
> maybe that should be built too before futzing with insecurity policies?
> 

Why do you assume anyone here on this thread can fix this?

Its up to the package maintainer to take a fix and ensure its well
tested, pointless fire-drill exercises might make you feel better,
but they don't help the distro.

Really all this bullshit in this thread, and not one patch? I think
ppl prefer hearing themselves spout than actually supply a fix.

Dave.


-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Question about tagging

[Jesse Keating]

On Wed, 2009-11-18 at 20:32 -0500, Alex Lancaster wrote:
> 
> Which component would be best to open a trac ticket for this
> functionality against? 

It basically needs to be fixed in Makefile.common, but my plan to fix it
involves getting rid of CVS all together, and while doing that getting
rid of the need for a common/ dir to carry around and update.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Seth Vidal]

On Wed, 18 Nov 2009, Matthew Miller wrote:


On Wed, Nov 18, 2009 at 11:45:14AM -0800, Dan Williams wrote:

But that's not right because those files aren't config files.  Instead,
you drop "local authority" files in /var/lib/polkit-1/localauthority/
that override those permissions on a site-by-site basis for your
specific use-case, irregardless of what the defaults are.


The config files live in /var?

Really.


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

bug is already opened.

-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Fedora rawhide rebuild in mock status 2009-11-18 i386

[Matt Domsch]

Fedora Rawhide-in-Mock Build Results for i386
using the rawhide tree as of 2009-11-15.  All packages were built on
systems running Fedora 12.  All failed builds were retried to avoid
single or transient build failures.

Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/


6 Open Bugs which now build, and can be marked CLOSED RAWHIDE:
gmpc: [u'530858']
gnubversion: [u'511678']
latex2rtf: [u'530856']
libfakekey: [u'511716']
matchbox-keyboard: [u'511774']
safekeep: [u'511793']

Total packages: 8599
Number failed to build: 357
Number expected to fail due to ExclusiveArch or ExcludeArch: 15
Leaving:  342

Of those expected to have worked...
Without a bug filed: 321
--
GMT-4.5.1-1.fc13 (build/make) orion,pertusus
Glide3-20050815-9.fc12 (build/make) ajax
Io-language-20071010-10.fc11 (build/make) orphan
LabPlot-1.6.0.2-8.fc12 (build/make) chitlesh,chitlesh,tnorth
OpenSceneGraph-2.8.2-3.fc12 (build/make) corsepiu
PyKDE-3.16.3-2.fc12 (build/make) rdieter,jamatos
PyQuante-1.6.3-2.fc12 (build/make) jussilehtola
R-AnnotationDbi-1.6.1-1.fc12 (build/make) pingou
R-BSgenome-1.12.3-2.fc12 (build/make) pingou
R-BSgenome.Celegans.UCSC.ce2-1.3.13-4.fc12 (build/make) pingou
R-Biobase-2.4.1-2.fc12 (build/make) pingou
R-Biostrings-2.12.9-1.fc12 (build/make) pingou
R-BufferedMatrix-1.8.0-2.fc12 (build/make) pingou
R-BufferedMatrixMethods-1.8.0-4.fc12 (build/make) pingou
R-DBI-0.2-4.fc12 (build/make) nigelj
R-DynDoc-1.22.0-2.fc12 (build/make) pingou
R-GeneR-2.14.0-2.fc12 (build/make) pingou
R-IRanges-1.2.3-2.fc12 (build/make) pingou
R-RM2-0.0-5.fc12 (build/make) denisarnaud
R-RODBC-1.3.0-1.fc12 (build/make) spot
R-RSQLite-0.7-4.fc12 (build/make) nigelj
R-RUnit-0.4.22-2.fc12 (build/make) pingou
R-abind-1.1.0-5.fc12 (build/make) spot
R-acepack-1.3.2.2-7.fc12 (build/make) spot
R-affy-1.22.1-3.fc12 (build/make) pingou
R-affyio-1.12.0-3.fc12 (build/make) pingou
R-biglm-0.7-1.fc12 (build/make) spot
R-bigmemory-3.10-1.fc12 (build/make) spot
R-hgu95av2probe-2.4.0-2.fc12 (build/make) pingou
R-lmtest-0.9-6.fc12 (build/make) orion
R-maanova-1.14.0-1.fc12 (build/make) pingou
R-msm-0.9.1-3.fc12 (build/make) denisarnaud
R-multtest-2.0.0-2.fc12 (build/make) pingou,alexlan
R-mvtnorm-0.9-8.fc12 (build/make) orion
R-nws-2.0.0.3-1.fc13 (build/make) spot
R-pls-2.1.0-2.fc12 (build/make) pingou
R-preprocessCore-1.6.0-2.fc12 (build/make) pingou
R-qtl-1.14.2-1.fc13 (build/make) ellert
R-qvalue-1.18.0-2.fc12 (build/make) pingou
R-rlecuyer-0.2-3.fc12 (build/make) pingou
R-systemfit-1.1-1.fc12 (build/make) orion
R-tkWidgets-1.22.0-2.fc12 (build/make) pingou
R-widgetTools-1.22.0-2.fc12 (build/make) pingou
UnihanDb-5.1.0-7.fc12.2 (build/make) dchen,i18n-team
aimage-3.2.1-1.fc12 (build/make) kwizart
aldo-0.7.5-4.fc12 (build/make) bjensen,bjensen,dp67,sconklin,sindrepb
anjal-0.1.0-1.fc13 (build/make) pbrobinson
apbs-1.1.0-7.fc12 (build/make) timfenn
arm-gp2x-linux-SDL-1.2.9-6.fc12 (build/make) jwrdegoede
arm-gp2x-linux-gcc-4.1.2-11.fc12 (build/make) jwrdegoede
arm-gp2x-linux-glibc-2.3.6-7.fc12 (build/make) jwrdegoede
arm-gp2x-linux-zlib-1.2.3-8.fc12 (build/make) jwrdegoede
arts-1.5.10-8.fc12 (build/make) than,kkofler,rdieter,tuxbrewr
asio-1.4.1-2.fc12 (build/make) uwog
atlas-3.8.3-12.fc13 (build/make) deji,deji
automake15-1.5-27 (build/make) karsten
awn-extras-applets-0.3.2.1-8.fc11 (build/make) phuang,sindrepb
baekmuk-bdf-fonts-2.2-8.fc12 (build/make) cchance,fonts-sig,i18n-team,petersen
ballbuster-1.0-9.fc12 (build/make) jwrdegoede
beagle-0.3.9-15.fc12 (build/make) nushio,psytux
bind-dyndb-ldap-0.1.0-0.3.a1.fc12 (build/make) mnagy,atkac
blacs-1.1-33.fc12 (build/make) spot
blitz-0.9-12.fc12 (build/make) sergiopr
bluefish-1.0.7-8.fc12 (build/make) pghmcfc
boo-0.9.2.3383-3.fc13 (build/make) pfj,palango
bro-1.4-0.6.20080804svn.fc12 (build/make) mildew,pvrabec
buildbot-0.7.11p3-1.fc12 (build/make) giallu,dmalcolm,smilner
cadaver-0.23.2-6 (build/make) jorton
cdrdao-1.2.3-0.rc2.4 (build/make) rrakus,denis,npajkovs
cdrkit-1.1.9-10.fc12 (build/make) rrakus,npajkovs
chronojump-0.8.11-3.fc12 (build/make) olea,salimma
cld-0.3-0.3.g3fc1d60a.fc13 (build/make) jgarzik,zaitcev
clisp-2.47-4.fc12 (build/make) gemi,green
clutter-gtk-0.10.2-1.fc12 (build/make) itamarjp,sundaram
cobbler-2.0.0-1.fc12 (build/make) jeckersb,awood,dgoodwin,jeckersb
cryptopp-5.6.0-4.fc13 (build/make) sundaram,nucleo
cuetools-1.4.0-0.5.svn305.fc12 (build/make) stingray
davfs2-1.3.3-3.fc12 (build/make) wwoods
dnsperf-1.0.1.0-12.fc12 (build/make) pwouters
eclipse-eclox-0.8.0-3.20090616svn.fc12 (build/make) chitlesh
eclipse-mylyn-3.3.0-3.fc13 (build/make) overholt,mbooth
eclipse-subclipse-1.6.5-1.fc12 (build/make) robmv,akurtakov
efte-1.1-1.fc12 (build/make) jussilehtola
emacs-bbdb-2.35-3.fc12 (build/make) jgu
emacs-common-muse-3.12-3.fc12 (build/make) jgu
emacs-vm-8.0.12-5.fc12 (build/make) jgu
emacspeak-29.0-3.fc12 (build/make) petersen
evolution-2.28.0-2.fc12 (build/make) mbarnes,mbarnes,mcrha
evolution-couchdb-0.3.2-2.fc13 (build/make) pbrobinson
evolutio

Fedora rawhide rebuild in mock status 2009-11-18 x86_64

[Matt Domsch]

Fedora Rawhide-in-Mock Build Results for x86_64
using the rawhide tree as of 2009-11-15.  All packages were built on
systems running Fedora 12.  All failed builds were retried to avoid
single or transient build failures.

Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/


6 Open Bugs which now build, and can be marked CLOSED RAWHIDE:
gmpc: [u'530858']
gnubversion: [u'511678']
latex2rtf: [u'530856']
libfakekey: [u'511716']
matchbox-keyboard: [u'511774']
safekeep: [u'511793']

Total packages: 8598
Number failed to build: 373
Number expected to fail due to ExclusiveArch or ExcludeArch: 31
Leaving:  342

Of those expected to have worked...
Without a bug filed: 320
--
GMT-4.5.1-1.fc13 (build/make) orion,pertusus
Glide3-20050815-9.fc12 (build/make) ajax
Io-language-20071010-10.fc11 (build/make) orphan
LabPlot-1.6.0.2-8.fc12 (build/make) chitlesh,chitlesh,tnorth
OpenSceneGraph-2.8.2-3.fc12 (build/make) corsepiu
PyKDE-3.16.3-2.fc12 (build/make) rdieter,jamatos
PyQuante-1.6.3-2.fc12 (build/make) jussilehtola
R-AnnotationDbi-1.6.1-1.fc12 (build/make) pingou
R-BSgenome-1.12.3-2.fc12 (build/make) pingou
R-BSgenome.Celegans.UCSC.ce2-1.3.13-4.fc12 (build/make) pingou
R-Biobase-2.4.1-2.fc12 (build/make) pingou
R-Biostrings-2.12.9-1.fc12 (build/make) pingou
R-BufferedMatrix-1.8.0-2.fc12 (build/make) pingou
R-BufferedMatrixMethods-1.8.0-4.fc12 (build/make) pingou
R-DBI-0.2-4.fc12 (build/make) nigelj
R-DynDoc-1.22.0-2.fc12 (build/make) pingou
R-GeneR-2.14.0-2.fc12 (build/make) pingou
R-IRanges-1.2.3-2.fc12 (build/make) pingou
R-RM2-0.0-5.fc12 (build/make) denisarnaud
R-RODBC-1.3.0-1.fc12 (build/make) spot
R-RSQLite-0.7-4.fc12 (build/make) nigelj
R-RUnit-0.4.22-2.fc12 (build/make) pingou
R-abind-1.1.0-5.fc12 (build/make) spot
R-acepack-1.3.2.2-7.fc12 (build/make) spot
R-affy-1.22.1-3.fc12 (build/make) pingou
R-affyio-1.12.0-3.fc12 (build/make) pingou
R-biglm-0.7-1.fc12 (build/make) spot
R-bigmemory-3.10-1.fc12 (build/make) spot
R-hgu95av2probe-2.4.0-2.fc12 (build/make) pingou
R-lmtest-0.9-6.fc12 (build/make) orion
R-maanova-1.14.0-1.fc12 (build/make) pingou
R-msm-0.9.1-3.fc12 (build/make) denisarnaud
R-multtest-2.0.0-2.fc12 (build/make) pingou,alexlan
R-mvtnorm-0.9-8.fc12 (build/make) orion
R-nws-2.0.0.3-1.fc13 (build/make) spot
R-pls-2.1.0-2.fc12 (build/make) pingou
R-preprocessCore-1.6.0-2.fc12 (build/make) pingou
R-qtl-1.14.2-1.fc13 (build/make) ellert
R-qvalue-1.18.0-2.fc12 (build/make) pingou
R-rlecuyer-0.2-3.fc12 (build/make) pingou
R-systemfit-1.1-1.fc12 (build/make) orion
R-tkWidgets-1.22.0-2.fc12 (build/make) pingou
R-widgetTools-1.22.0-2.fc12 (build/make) pingou
UnihanDb-5.1.0-7.fc12.2 (build/make) dchen,i18n-team
aimage-3.2.1-1.fc12 (build/make) kwizart
aldo-0.7.5-4.fc12 (build/make) bjensen,bjensen,dp67,sconklin,sindrepb
anjal-0.1.0-1.fc13 (build/make) pbrobinson
apbs-1.1.0-7.fc12 (build/make) timfenn
arm-gp2x-linux-SDL-1.2.9-6.fc12 (build/make) jwrdegoede
arm-gp2x-linux-gcc-4.1.2-11.fc12 (build/make) jwrdegoede
arm-gp2x-linux-glibc-2.3.6-7.fc12 (build/make) jwrdegoede
arm-gp2x-linux-zlib-1.2.3-8.fc12 (build/make) jwrdegoede
arts-1.5.10-8.fc12 (build/make) than,kkofler,rdieter,tuxbrewr
asio-1.4.1-2.fc12 (build/make) uwog
atlas-3.8.3-12.fc13 (build/make) deji,deji
automake15-1.5-27 (build/make) karsten
awn-extras-applets-0.3.2.1-8.fc11 (build/make) phuang,sindrepb
baekmuk-bdf-fonts-2.2-8.fc12 (build/make) cchance,fonts-sig,i18n-team,petersen
ballbuster-1.0-9.fc12 (build/make) jwrdegoede
beagle-0.3.9-15.fc12 (build/make) nushio,psytux
bind-dyndb-ldap-0.1.0-0.3.a1.fc12 (build/make) mnagy,atkac
blacs-1.1-33.fc12 (build/make) spot
blitz-0.9-12.fc12 (build/make) sergiopr
bluefish-1.0.7-8.fc12 (build/make) pghmcfc
boo-0.9.2.3383-3.fc13 (build/make) pfj,palango
botan-1.8.7-1.fc12 (build/make) thm
bro-1.4-0.6.20080804svn.fc12 (build/make) mildew,pvrabec
buildbot-0.7.11p3-1.fc12 (build/make) giallu,dmalcolm,smilner
cadaver-0.23.2-6 (build/make) jorton
cdrdao-1.2.3-0.rc2.4 (build/make) rrakus,denis,npajkovs
cdrkit-1.1.9-10.fc12 (build/make) rrakus,npajkovs
chktex-1.6.4-4.fc11 (build/make) sergiopr,pertusus
chronojump-0.8.11-3.fc12 (build/make) olea,salimma
clisp-2.47-4.fc12 (build/make) gemi,green
clutter-gtk-0.10.2-1.fc12 (build/make) itamarjp,sundaram
cobbler-2.0.0-1.fc12 (build/make) jeckersb,awood,dgoodwin,jeckersb
cryptopp-5.6.0-4.fc13 (build/make) sundaram,nucleo
davfs2-1.3.3-3.fc12 (build/make) wwoods
dnsperf-1.0.1.0-12.fc12 (build/make) pwouters
eclipse-eclox-0.8.0-3.20090616svn.fc12 (build/make) chitlesh
eclipse-mylyn-3.3.0-3.fc13 (build/make) overholt,mbooth
eclipse-subclipse-1.6.5-1.fc12 (build/make) robmv,akurtakov
efte-1.1-1.fc12 (build/make) jussilehtola
emacs-bbdb-2.35-3.fc12 (build/make) jgu
emacs-common-muse-3.12-3.fc12 (build/make) jgu
emacs-vm-8.0.12-5.fc12 (build/make) jgu
emacspeak-29.0-3.fc12 (build/make) petersen
evolution-2.28.0-2.fc12 (build/make) mbarnes,mbarnes,mcrha
evolution-couchdb-0.3.2-2.fc13 (build/make) pbrobinson
evolution-exchange-2.28.0-1.

Re: Local users get to play root?

[Adam Williamson]

On Wed, 2009-11-18 at 20:20 -0600, Mike McGrath wrote:

> > 5) The people who want this new security policy should add an opt-in 
> > checkbox
> > in Anaconda or firstboot.

> Does anyone disagree with anything in 1-5?  It all sounds reasonable to
> me?

I disagree with 5, that's not a sensible or sustainable way to deal with
this kind of thing. At least not without some kind of coherent process.
Just throwing in single-issue checkboxes ad hoc is not the way to do
this - should we have fifty checkboxes for everything you can configure
users to be able to do or not able to do? If we're going to go down that
route, it needs to be a properly planned utility, something like
Mandriva's msec. Only, uh, probably better.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Mail Llists]

 Jeff et al are 100% correct - why this is even debated is unfathomable
to me.

Surely it is completely obvious that the default should be off. (as it
was and will be in f13+).

 Why have we not got a revert fix to turn this back off in updates-testing ?

 Please fix it now - then discuss how to improve the desktop experiance
for Aunt tilly. But first put the security back to what it was, should
be and presumably will be again anyway.

 If people need it, add a button to the PK gui config tool. (WHat is it
called anyway?) - I cant seem to find a [gui] config tool of any kind -
maybe that should be built too before futzing with insecurity policies?

  gene/

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Adam Williamson]

On Wed, 2009-11-18 at 16:04 -0900, Jeff Spaleta wrote:

> And I think you missed my point. As we are learning..the hard way...
> sysadmins and spin developers can and should be encouraged to generate
> site specific policykit rules as part of hardening/softening ALL
> policykit enabled applications. You we really won't be able to rip out
> all the stuff using policykit.  We're gonna have to digest the fact
> that policykit is there and start dealing with it in our setups and we
> are going to need some hand holding so we can do it effectively.
> PackageKit's policy is just the beginning of the learning curve here.
> It may not be server relevant as an application.. but the underlying
> issue about checking and configuring PolicyKit settings will be server
> relevant and unavoidable at some point.

I agree, but I also agree with those who said that this issue makes it
very clear we need to have some kind of process for setting a general,
project-wide policy for what kind of policies packages should set via
PolicyKit; this needs to be handled in a joined-up way and with the
involvement of the appropriate people (i.e. the security group), not
just on an ad hoc level by individual package maintainers. This should
be something the FESCo discussion should cover, I think. We need to have
a proper definition of our desired default security posture, and proper
oversight of the implementation of this. Especially now PolicyKit usage
is becoming (rightly!) widespread.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Adam Williamson]

On Wed, 2009-11-18 at 19:34 -0500, Jeff Garzik wrote:

> IFF this feature was listed as a question in firstboot,

This is generally considered to be a bad way of organizing things.
Asking people vague questions about the intended role of the system or
the intended nature of a given user account is a great way to confuse
them into making the wrong choice, especially since it wouldn't be at
all obvious what the actual impact of each choice would be. I don't
think that's the answer here. (frankly I'm a bit dubious about the plan
to introduce a simplistic 'user / administrator' paradigm, but that's a
wider topic).

> and IFF this feature was explained in detail in release notes, then there 
> would have been no problem at all...

it is now :)
http://docs.fedoraproject.org/release-notes/f12/en-US/html/sect-Release_Notes-Security.html
 (but yes, obviously this should have happened way before release)

> You also omitted the case where admins of servers upgrade into a less 
> secure policy.  PackageKit presence does not imply desktop user.

i'm really not losing any sleep about that vector. if your server allows
untrusted people to have local login access it is a badly configured
server and you probably have more severe problems to worry about. the
impact on _non_-server machines is more significant, to my mind.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Keith G. Robertson-Turner]

Verily I say unto thee, that Seth Vidal spake thusly:
> On Wed, 18 Nov 2009, nodata wrote:

>> This is a major change. I vote for secure by default.
>> 
>> If the admin wishes this "surprise-root" feature to be enabled he
>> can enable it.
> 
> I'm not sure how this is 'surprise root'. IT will only allow installs
> of pkgs signed with a key you trust from a repo you've setup.
> 
> which pretty much means: if the admin trusts the repo, then it is
> okay.

You mean a trusted repo like this (serious question)?:

[quote]
Last week we discovered that some Fedora servers were illegally
accessed. The intrusion into the servers was quickly discovered, and the
servers were taken offline.

...

One of the compromised Fedora servers was a system used for signing
Fedora packages. However, based on our efforts, we have high confidence
that the intruder was not able to capture the passphrase used to secure
the Fedora package signing key.
[/quote]

https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012.html

Did the review process for this fundamental change in Fedora's security,
consider the impact of what could easily have been a serious compromise
to the primary repos.

Combine a potential worst-case outcome in the above incident, with root
privileges to unauthorised users installing or upgrading packages, and
the result is a disaster on several levels, not least of which is the PR
impact for Red Hat.

Will someone at Fedora start taking this issue seriously soon?

-- 
Regards,
Keith G. Robertson-Turner

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root? (link to Public Google Wave on the topic)

[Mike A. Harris]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

nodata wrote:
> Yikes! When was it decided that non-root users get to play root?
> 
> Ref:
>  https://bugzilla.redhat.com/show_bug.cgi?id=534047
> 
> This is horrible!

As an experiment to see how well Google Wave might handle such a higher
conversation topic, I've started a neutral public wave on the topic
which points out some perceived security threats:

https://wave.google.com/wave/#restored:wave:googlewave.com!w%252Bm34xWBSKA.1

Feel free to chime in with (hopefully) constructive thoughts/feedback
there as well.


- --
Mike A. Harris   Website: http://mharris.ca
Google Wave: mike.andrew.harris - at - googlewave.com
https://identi.ca/mharris | https://twitter.com/mikeaharris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFLBMPI4RNf2rTIeUARAqPjAJsHjJweh44nz88fQKzYvy/lGhx+ewCfRnwN
NrcmGVL7MR1IqLtaykZuYyc=
=zhJB
-END PGP SIGNATURE-

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Review request...

[David Nalley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On Wed, Nov 18, 2009 at 10:24 PM, Nathanael D. Noblet  wrote:
> On 11/18/2009 06:23 PM, Kevin Kofler wrote:
>>
>> Michael Schwendt wrote:
>>>
>>> Many packagers don't know that maintaining a proper spec %changelog for
>>> relevant spec file changes and %release bumps are considered important
>>> during review already. Others add meaningless/dummy %changelog entries
>>> even in Fedora cvs.
>>
>> But that's a people issue that needs to be solved, not papered over in the
>> name of "being nice".
>>
>> Sadly, "incompetence" as in unfamiliarity with guidelines which are
>> assumed
>> to be prerequisites for proper packaging is growing in our ranks (both
>> from
>> new packagers and from people who ought to know better), something needs
>> to
>> be done about it.
>
> For sure. Personally I've been using Redhat/Fedora for years now, but this
> is my first package submission to fedora. I've wanted to get involved for
> awhile now. I had read the guidelines, and honestly want to provide a
> properly configured package. I think (and this very well could have been a
> language issue) that knowing what the issue I'm missing in my current spec
> would help immensely. I mean I know there are packaging guidelines, and
> there is a lot of information there, so it is plausible for someone new not
> to see sub documentation or notice that their spec isn't in compliance.
> Having the exact issue pointed out helps with the learning. Is there a
> 'ReviewingReviews' guideline? Would that even help?
>
> Anyway, I hope to get some feedback on the actual review too, but I mainly
> started this thread because I wasn't sure what I wasn't doing. I was asked
> for a scratch build which I *thought* I had provided a link to. I provided
> links to spec files and srpms. However was continually being asked for that
> same thing, and the requests and my responses were obviously not being
> understood by either party. I posted to make sure I wasn't missing something
> obvious, some guideline of 'Here's how to post your spec file, srpm and
> scratch build', if I wasn't doing it correctly.
>
> Sincerely trying to provide the best package I can,
> Nathanael
>

There is a Review Guidelines page that is supposed to be the basis for
package reviews:
http://fedoraproject.org/wiki/Packaging/ReviewGuidelines but they
honestly only scratch the bare minimum of the full set of Packaging
Guidelines.

My take, as a comparatively inexperienced packager, is that packaging
is such a wide ranging subject that it's not something that you can
gain proficiency at without gaining the experience of doing it a lot,
and in the process failing a lot and learning from the failure.

6 months from now, you'll likely look back on your first few packages,
as I did, and wonder 'how did that ever pass the review process?', or
'what was my sponsor thinking when he approved of me?'.

The packaging guidelines, are honestly sooo voluminous, and also so
scattered, that it's an interesting problem for new packagers, and the
getting started as a packager documentation is the same way. Much of
that could be improved (and at one time there was an effort going on
towards that end.) but it will never become 'easy'. In the end, don't
hesitate to ask for help or say you don't know. Part of the process is
learning how to become effectively lost. Failure, within Fedora is OK,
and even encouraged, provided you correct it and learn from it.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.10)

iEYEARECAAYFAksEwFIACgkQkZOYj+cNI1fNxACgqS4lso7EkKaCpmGURK0G0TZH
s24An0ryEFUdt8sE1TgvOScN9hJKRC7w
=PBdd
-END PGP SIGNATURE-

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Kevin Kofler]

Richard Hughes wrote:
> F11 had retained authorisations, which arguably were more of a
> security weakness.

How's a retained autorization (ask for the root password once, remember the 
authorization (NOT the password! I know you know this, but I'm pointing this 
out for other readers who might fall into this common confusion)) less 
secure than a blanket authorization (don't ask for the root password at all, 
have the authorization pre-"remembered")?

Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

[King InuYasha]

On Wed, Nov 18, 2009 at 8:30 PM, Ikem Krueger
wrote:

> >> Why then should someone prefer 64bit over 32bit?
>
> > 4 Reasons:
>
> > 1: Date/Time stamp, Unix time doesn't work in 32-bit past 2038 (not
> really affecting us much, most of us will replace our PCs long before then)
>
> What do the people with 32bit cpus who won't/can't upgrade?
>
>
Then the Y2k38 problem occurs, which is what the theoretical Y2K problem
would have been.



> > 2: Access more than 4GB of RAM (definitely becoming increasingly
> important)
>
> I hope for the apps, not for the system. I don't want to become Linux
> the next Vista..
>

It isn't the OS itself that will be requiring more than 4GB of RAM (at least
I hope not in Linux, Windows is a lost cause... Perhaps ReactOS will pull it
off?), but rather the applications used on the computer. Nowadays, it isn't
unusual for applications to require at least 512MB of RAM. That builds up,
quite quickly.



>
> > 3: Enhanced performance-critical computational capabilities (if you do a
> lot of complex HD photo, HD video, or HD audio work, or if you do a lot of
> raw complex math on your computer, this is EXTREMELY important)
>
> > 4: Better virtual machine performance
>
> Thanks for the answer. :)
>
>
You're welcome ;)
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Keith G. Robertson-Turner]

Verily I say unto thee, that nodata spake thusly:

> Secure by default please, otherwise turn off selinux by default.

Very good point.

It's rather contradictory, indeed hypocritical, for Fedora to have spent
all this time and effort integrating security as relatively extreme as
SELinux into the distro, only to then undermine it by allowing a subset
of unauthorised root privileges.

So on the one hand the rationale is: The target audience is single-user
desktops, so authorising package installs is moot. But on the other hand
those same users had to endure several releases where SELinux prevented
many packages from working correctly, while maintainers, developers, and
bug reporters spent a lot of time and effort tweaking security policies
to fix these issues, for the sake of what was extolled as important and
necessary improvements to Linux security.

So which is it?

Is security important for the target audience (whomever Fedora presumes
them to be), or not?

Personally, I use Fedora on desktops, laptops /and/ servers, and yes I
have other users on my network, to whom I do /not/ wish to allow root
access ... ever. And I take great exception to Fedora arrogantly
presuming what type of systems I use Fedora on, and what my security
needs are.

Something far more worrying, is that Fedora is the testbed for RHEL. Are
we to assume that enterprise customers will be spared the insecurities
currently being foisted on Fedora users, or should we start working on
the security advisories now?

-- 
Regards,
Keith G. Robertson-Turner

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Kevin Kofler]

Rick L Vinyard Jr wrote:
> It would seem that a middle ground could be struck here. Why not set the
> default to require admin privileges, and once the credentials have been
> established provide a check box user choice to change to the behavior
> that doesn't require privileges.

That's exactly how Fedora 9, 10 and 11 did things. It just worked. I have no 
idea why this got changed.

Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Rick L Vinyard Jr]

Bill Nottingham wrote:
> Eric Christensen (e...@christensenplace.us) said: 
>>> It's a behavior change, for sure. For people who want to lock down their
>>> systems, it's a default they will need to be able to change, and they
>>> should have been able to discover it through the normal mechanisms for
>>> that. (i.e., the release notes.). It likely should have been discussed
>>> when it was introduced - it's obviously not something that's applicable
>>> to all usage cases for the OS.
>> You are assuming that the users have physical access to the box and also
>> know how to get a root shell and that the box hasn't been hardened
>> (before the PK vulnerability was known).
> 
> Sure, I said 'out of the box'. Out of the box none of those other
> hardening steps are done either, which is why if this is a policy
> that we want, it should be documented as a hardening step that can
> be taken.
> 
> Bill
> 

It would seem that a middle ground could be struck here. Why not set the
default to require admin privileges, and once the credentials have been
established provide a check box user choice to change to the behavior
that doesn't require privileges.

That way, out of the box it's a little more locked down, but easily
changeable. This is a common UI pattern that you can see in many
applications that have security implications... Firefox is a primary
example.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Kevin Kofler]

Konstantin Ryabitsev wrote:
> but a user who installs Fedora at home will probably welcome not having to
> type in a root password when they want to install a gimp plugin.

They didn't with the old policy either unless it's the very first time they 
install a package. With the F11 policy (which I propose to go back to), 
authentication was required EXACTLY ONCE for a user account. How is that a 
big issue for this use case? Yet, it solves the problem of unauthorized 
people installing stuff. So why was this changed?

Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Review request...

[Rahul Sundaram]

On 11/19/2009 08:54 AM, Nathanael D. Noblet wrote:

> Anyway, I hope to get some feedback on the actual review too, but I
> mainly started this thread because I wasn't sure what I wasn't doing. I
> was asked for a scratch build which I *thought* I had provided a link
> to. I provided links to spec files and srpms. However was continually
> being asked for that same thing, and the requests and my responses were
> obviously not being understood by either party. I posted to make sure I
> wasn't missing something obvious, some guideline of 'Here's how to post
> your spec file, srpm and scratch build', if I wasn't doing it correctly.
> 
> Sincerely trying to provide the best package I can,

You are doing fine. Just continue with review.

Rahul

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Review request...

[Nathanael D. Noblet]

On 11/18/2009 06:23 PM, Kevin Kofler wrote:

Michael Schwendt wrote:

Many packagers don't know that maintaining a proper spec %changelog for
relevant spec file changes and %release bumps are considered important
during review already. Others add meaningless/dummy %changelog entries
even in Fedora cvs.


But that's a people issue that needs to be solved, not papered over in the
name of "being nice".

Sadly, "incompetence" as in unfamiliarity with guidelines which are assumed
to be prerequisites for proper packaging is growing in our ranks (both from
new packagers and from people who ought to know better), something needs to
be done about it.


For sure. Personally I've been using Redhat/Fedora for years now, but 
this is my first package submission to fedora. I've wanted to get 
involved for awhile now. I had read the guidelines, and honestly want to 
provide a properly configured package. I think (and this very well could 
have been a language issue) that knowing what the issue I'm missing in 
my current spec would help immensely. I mean I know there are packaging 
guidelines, and there is a lot of information there, so it is plausible 
for someone new not to see sub documentation or notice that their spec 
isn't in compliance. Having the exact issue pointed out helps with the 
learning. Is there a 'ReviewingReviews' guideline? Would that even help?


Anyway, I hope to get some feedback on the actual review too, but I 
mainly started this thread because I wasn't sure what I wasn't doing. I 
was asked for a scratch build which I *thought* I had provided a link 
to. I provided links to spec files and srpms. However was continually 
being asked for that same thing, and the requests and my responses were 
obviously not being understood by either party. I posted to make sure I 
wasn't missing something obvious, some guideline of 'Here's how to post 
your spec file, srpm and scratch build', if I wasn't doing it correctly.


Sincerely trying to provide the best package I can,
Nathanael

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Kevin Kofler]

Bruno Wolff III wrote:
> I don't like the idea of packages being installed meaning I want them to
> run services, schedule cron jobs or give elevated access by default. This
> kind of thing makes it easy to shoot yourself in the foot. The purpose of
> not installing packages should be to save disk space and resources needed
> for updates, not security and integrity.

And the very ironic thing about all this is that the very proposed 
"solution" ("don't install package XYZ if you don't want the reduced 
security that comes with it") is exactly why this very "feature" is such a 
bad idea!

Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: RFC: Btrfs snapshots feature for F13

[Josef Bacik]

On Wed, Nov 18, 2009 at 8:13 PM, Kevin Kofler  wrote:
> Chris Ball wrote:
>> Creating a new snapshot is unprivileged
>
> Huh? Isn't that a license for any user to waste massive amounts of disk
> space, ignoring any per-user quota? Whole file system operations must be
> root only!
>

Snapshots are subject to the permissions of the root inode that we're
snapshotting, so if the permissions are set such that the user has
write permissions for that root, then they can create snapshots.  An
example of this would be if you created individual subvolumes for
individual home directories.  The users would have permissions to
their respective roots and be allowed to snapshot them.  This isn't a
whole file system operation, its a per-root operation.  Thanks,

Josef

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Kevin Kofler]

Jeff Spaleta wrote:
> Beyond the issue of what is and what is not the appropriate default at
> install time..which is already a difficult issue to talk through.  I
> think there is an education gap here about how to competently admin
> PolicyKit based activities which adds frustration.

Another big issue is that polkit-gnome-authorization and polkit-kde-
authorization were not ported to / rewritten for PolicyKit 1, I've been told 
a polkit-gnome-authorization port/rewrite is not even planned anymore 
(despite having originally been a requirement for PolicyKit 1 and despite 
this being a major feature regression compared to 0.9), and the polkit-kde-
authorization port/rewrite is planned, but not even started (the people 
working on it are still busy with making the rest of PolicyKit 1 KDE 
integration happen).

The absence of a GUI policy editor combined with lack of documentation for 
the config files makes bad defaults a big issue.

Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Xorg and multitouch

[Peter Hutterer]

On Wed, Nov 18, 2009 at 12:09:48PM -0500, Jarod Wilson wrote:
> On 11/17/09 9:14 PM, Chris Ball wrote:
> >Hi,
> >
> >>  Multitouch means, several mousepointers and you can move them all
> >>  seperately.
> >
> >No, that's what multi-pointer means.  Multi-Pointer X is already in
> >F12.
> ...
> >Multitouch refers to technologies that involve extrapolating from
> >motion of finger-shaped blobs on your input device to the idea that
> >a user has performed some continuous motion with said finger(s), and
> >reacting appropriately.  It's not the same as multi-pointer X, but it
> >does use the same core technology.
> 
> Isn't two-finger-drag for scrolling and two-finger-taps for
> right-click a form of multitouch? Or are we talking about extending
> that to pinch, rotate, etc?

There's a very subtle difference between multi-pointer and multi-touch and
the term multi-touch is quite overloaded.

In general, multi-pointer means you have multiple virtual input points that
are used simultaneously. The input points are distinct and trackable over
time though it is not always possible to map input points to users. Compare
two-handed input with multi-user input (or the combination of both).
This is implemented by providing two or more mouse cursors and keyboard
foci.

Multi-touch in its very literal term is direct-touch input providing
multiple points simultanously. Multi-touch can be multi-pointer provided you
treat each input point as a distinct point. E.g. using two fingers to
do what you could do with a mouse, or two users simultaneously using one or
more fingers as a pointing device.
This is supported, though we have some work to do in terms of getting this
from the hardware to the server.

Next level up is using touch not only as a single point of input but rather
as a shape or area of input - it matters if you use a palm, fist, finger,
finger-tip, etc. Instead of x/y you have a lot more information now about
the nature of the touch. Multi-touch here is the same as multi-pointer with
more information per touch. We don't have that one yet.

Next level up is using touch as a number of transient, non-connected
physical input points/areas that are harder to map to virtual input points.
Putting all 5 fingers of one hand down to perform an action is not the same
as using 5 mouse cursors. Putting the two index fingers down otoh is. That's
where it gets tricky, especially in the light of multiple users and windowed
environments. We don't have support for that type of multi-touch yet.

That's a high-level view, there are some more details for each I've omitted.

Gestures are largely independent of the level of multipointer/multitouch
support. You can do pinch with two mouse pointers, to finger touches or some
fancy multi-touch input.

We have some rudimentary support for gestures (two-finger scrolling +
tapping) but nothing elborate. We could do bits and pieces in the driver,
but we lack a meaningful way to send the information to the client.

Cheers,
  Peter

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Kevin Kofler]

nodata wrote:
> It doesn't make sense to define the security setup of a machine based on
> "oh well packagekit is installed, so it must be a desktop machine for
> which there is one or maybe two primary users who are all trusted to
> decide if they want to install software".

And the irony in all this is that this "the security requirements of the 
machine are defined by what packages are, or rather are not, installed" 
assumption is exactly what makes this very "feature" such a security risk!

Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Review request...

[Josh Boyer]

On Wed, Nov 18, 2009 at 09:13:45PM -0500, Orcan Ogetbil wrote:
Sadly, "incompetence" as in unfamiliarity with guidelines which are
assumed to be prerequisites for proper packaging is growing in our ranks
(both from new packagers and from people who ought to know better),
something needs to be done about it.
>>>
>>> Such as?
>>
>> * Such as the very issue Michael Schwendt was pointing out (see quote).
>> * Such as continuous accidental upgrade path breakage due to widespread
>> unfamiliarity with Release/disttag handling (e.g. I keep having to explain
>> why and when to use -1.fc12.1 style versioning).
>> * Such as the assorted packaging mistakes which are caught by people
>> watching the commits list and pointed out on this list (with the offending
>> maintainer CCed).
>> etc.
>>
>
>I think he is asking what that "something" is when you said "something
>needs to be done about it."

Correct.

josh

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Kevin Kofler]

Simo Sorce wrote:
> In the meanwhile the F-11 policy was just fine.

+1

I really don't get why this was changed.

Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Eric Christensen]

On Thu, 2009-11-19 at 07:52 +0530, Rahul Sundaram wrote:
> On 11/19/2009 07:50 AM, Mike McGrath wrote:
> > On Wed, 18 Nov 2009, Jeff Garzik wrote:
> 
> >> 1) We should recognize this new policy departs from decades of Unix and 
> >> Linux
> >> sysadmin experience.
> >>
> >> 2) F12 policy should be reverted to F11, ASAP.  Possibly with a CVE.
> >>
> >> 3) Due to #1, F13+ should not deviate from the decades-old default.
> >>
> >> 4) Release notes should explain new [and after step #2, optional] policy in
> >> detail, including how to turn it off again.  Seth's laudable write-up 
> >> efforts
> >> should not have been necessary -- that info should be prepared.
> >>
> >> 5) The people who want this new security policy should add an opt-in 
> >> checkbox
> >> in Anaconda or firstboot.
> >
> > 
> > Does anyone disagree with anything in 1-5?  It all sounds reasonable to
> > me?
> 
> Release notes are being updated as we speak. I think, the "role" of a
> system, be it a personal desktop, workstation, server or something else
> can change post-installation as well. I don't think a simple checkbox in
> Anaconda is going to be useful enough. We need a tool to switch policies
> easily so that we can tweak the policies across a wide range of tools
> with things like PolicyKit and each of these policies can be written
> with particular audiences in mind.
> 
> Rahul
> 

I agree with 1-4 and Rahul.

--Eric 


signature.asc
Description: This is a digitally signed message part
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)

[Roland McGrath]

> Another data point for this thread:

x86 is unlike other architectures because 64-bit also has twice as many
registers as 32-bit.  So you get to trade off the benefits of register
allocation across more registers against the memory/cache footprint of
64-bit pointers.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)

[Chris Adams]

Once upon a time, Jeff Garzik  said:
> Running a 64-bit kernel with a 32-bit userland is a common practice on 
> non-x86 platforms, and non-Linux OS's.  For a lot of tasks, you simply 
> do not need 64-bit pointers and a 64-bit process address space.  Both 
> executable code and in-memory data structures tend to be smaller on 32-bit.

However, on x86, the 32->64 bit jump also gives a larger register set
and (IIRC) SSE (or SSE2?) on all chips, which allows better code
generation for all kinds of things.

The i386 architecture is register-starved compared to many other
architectures.
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

x86-64 on i386 (was Re: Promoting i386 version over x86_64?)

[Jeff Garzik]

Another data point for this thread:

Running a 64-bit kernel with a 32-bit userland is a common practice on 
non-x86 platforms, and non-Linux OS's.  For a lot of tasks, you simply 
do not need 64-bit pointers and a 64-bit process address space.  Both 
executable code and in-memory data structures tend to be smaller on 32-bit.


cp(1), for example, can be 32-bit as long as it supports O_LARGEFILE and 
off64_t.


Jeff




--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

[Ikem Krueger]

>> Why then should someone prefer 64bit over 32bit?

> 4 Reasons:

> 1: Date/Time stamp, Unix time doesn't work in 32-bit past 2038 (not really 
> affecting us much, most of us will replace our PCs long before then)

What do the people with 32bit cpus who won't/can't upgrade?

> 2: Access more than 4GB of RAM (definitely becoming increasingly important)

I hope for the apps, not for the system. I don't want to become Linux
the next Vista..

> 3: Enhanced performance-critical computational capabilities (if you do a lot 
> of complex HD photo, HD video, or HD audio work, or if you do a lot of raw 
> complex math on your computer, this is EXTREMELY important)

> 4: Better virtual machine performance

Thanks for the answer. :)

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Rahul Sundaram]

On 11/19/2009 07:50 AM, Mike McGrath wrote:
> On Wed, 18 Nov 2009, Jeff Garzik wrote:

>> 1) We should recognize this new policy departs from decades of Unix and Linux
>> sysadmin experience.
>>
>> 2) F12 policy should be reverted to F11, ASAP.  Possibly with a CVE.
>>
>> 3) Due to #1, F13+ should not deviate from the decades-old default.
>>
>> 4) Release notes should explain new [and after step #2, optional] policy in
>> detail, including how to turn it off again.  Seth's laudable write-up efforts
>> should not have been necessary -- that info should be prepared.
>>
>> 5) The people who want this new security policy should add an opt-in checkbox
>> in Anaconda or firstboot.
>
> 
> Does anyone disagree with anything in 1-5?  It all sounds reasonable to
> me?

Release notes are being updated as we speak. I think, the "role" of a
system, be it a personal desktop, workstation, server or something else
can change post-installation as well. I don't think a simple checkbox in
Anaconda is going to be useful enough. We need a tool to switch policies
easily so that we can tweak the policies across a wide range of tools
with things like PolicyKit and each of these policies can be written
with particular audiences in mind.

Rahul

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

[King InuYasha]

On Wed, Nov 18, 2009 at 8:18 PM, Ikem Krueger
wrote:

> > Except, that could be false advertising. In most cases, where CPU
> > computation is not used heavily, 64-bit is actually SLOWER than the
> 32-bit
> > counterpart. Optimizations are narrowing the gap, but it still remains
> > true.
>
> Why then should someone prefer 64bit over 32bit?
>
>
4 Reasons:

1: Date/Time stamp, Unix time doesn't work in 32-bit past 2038 (not really
affecting us much, most of us will replace our PCs long before then)

2: Access more than 4GB of RAM (definitely becoming increasingly important)

3: Enhanced performance-critical computational capabilities (if you do a lot
of complex HD photo, HD video, or HD audio work, or if you do a lot of raw
complex math on your computer, this is EXTREMELY important)

4: Better virtual machine performance
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

[Ikem Krueger]

> That gives very little incentive to fetch the correct version.

Why should a person bother with it, when a pc can do that?

> And I think that by now the vast majority of our userbase uses 64-bit-capable 
> machines.

I don't know. Maybe a poll would be good for that? :)

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Mike McGrath]

On Wed, 18 Nov 2009, Jeff Garzik wrote:

> On 11/18/2009 07:45 PM, Mike McGrath wrote:
> > Stick with the facts, be clear about what you're
> > trying to accomplish (changing it back in F13?  Changing it back in F12?
> > Setting a policy so stuff like this doesn't happen again?)
>
>
> 1) We should recognize this new policy departs from decades of Unix and Linux
> sysadmin experience.
>
> 2) F12 policy should be reverted to F11, ASAP.  Possibly with a CVE.
>
> 3) Due to #1, F13+ should not deviate from the decades-old default.
>
> 4) Release notes should explain new [and after step #2, optional] policy in
> detail, including how to turn it off again.  Seth's laudable write-up efforts
> should not have been necessary -- that info should be prepared.
>
> 5) The people who want this new security policy should add an opt-in checkbox
> in Anaconda or firstboot.
>


Does anyone disagree with anything in 1-5?  It all sounds reasonable to
me?

-Mike

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

[Ikem Krueger]

> Except, that could be false advertising. In most cases, where CPU
> computation is not used heavily, 64-bit is actually SLOWER than the 32-bit
> counterpart. Optimizations are narrowing the gap, but it still remains
> true.

Why then should someone prefer 64bit over 32bit?

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: F12: where did window properties go?

[Rahul Sundaram]

On 11/19/2009 07:40 AM, Kevin Kofler wrote:
> Rahul Sundaram wrote:
>> control-center-extra isn't there in upstream releases of GNOME afaik.
> 
> So what? Neither is Firefox and it's installed by default in our GNOME spin 
> and many other GNOME-based distros.

You are comparing a entirely different program to a preference window.
Not exactly the same thing. Instead of arguing with me, just wait and
watch the next round of releases with GNOME and you will see my point.

Rahul

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

[Kevin Kofler]

Ikem Krueger wrote:
> "You're pc could be run faster, if you upgrade this operating system
> to the 64bit version of it. You can download them here if you like:
> [Link]"

That gives very little incentive to fetch the correct version. Making the 
optimistic assumption and saying "I'm sorry, but this version won't work" in 
the failure case will definitely get everybody to use the optimal version 
for their machine. And I think that by now the vast majority of our userbase 
uses 64-bit-capable machines.

Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Review request...

[Orcan Ogetbil]

On Wed, Nov 18, 2009 at 9:00 PM, Kevin Kofler wrote:
> Josh Boyer wrote:
>
>> On Thu, Nov 19, 2009 at 02:23:22AM +0100, Kevin Kofler wrote:
>>>Michael Schwendt wrote:
 Many packagers don't know that maintaining a proper spec %changelog for
 relevant spec file changes and %release bumps are considered important
 during review already. Others add meaningless/dummy %changelog entries
 even in Fedora cvs.
>>>
>>>But that's a people issue that needs to be solved, not papered over in the
>>>name of "being nice".
>>>
>>>Sadly, "incompetence" as in unfamiliarity with guidelines which are
>>>assumed to be prerequisites for proper packaging is growing in our ranks
>>>(both from new packagers and from people who ought to know better),
>>>something needs to be done about it.
>>
>> Such as?
>
> * Such as the very issue Michael Schwendt was pointing out (see quote).
> * Such as continuous accidental upgrade path breakage due to widespread
> unfamiliarity with Release/disttag handling (e.g. I keep having to explain
> why and when to use -1.fc12.1 style versioning).
> * Such as the assorted packaging mistakes which are caught by people
> watching the commits list and pointed out on this list (with the offending
> maintainer CCed).
> etc.
>

I think he is asking what that "something" is when you said "something
needs to be done about it."

Orcan

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

[King InuYasha]

On Wed, Nov 18, 2009 at 8:04 PM, Ikem Krueger
wrote:

> > IMHO, the right solution is to make the 64-bit edition the default
> download
> > and to work on making the error message people get when trying to install
> it
> > on a 32-bit machine nicer: "We're sorry, but your computer is too old to
> > install this 64-bit version of Fedora. Please download the legacy 32-bit
> > edition instead."
>
> That would be an aweful first experience. Imagine her thoughts: "Oh. I
> made something wrong.. Maybe it's nothing for me.."
>
> I suggest to let it as it is and check the system (if 64bit or 32bit)
> when it is running.
>
> Maybe then a little popup comes up with something like:
>
> "You're pc could be run faster, if you upgrade this operating system
> to the 64bit version of it. You can download them here if you like:
> [Link]"
>
> Even better would be:
>
> "You're pc could be run faster, if you upgrade this operating system
> to the 64bit version of it. You can do so by clicking here: [Button]"
>
>
>
Except, that could be false advertising. In most cases, where CPU
computation is not used heavily, 64-bit is actually SLOWER than the 32-bit
counterpart. Optimizations are narrowing the gap, but it still remains
true.
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

[Ikem Krueger]

> Yeah, they're a huge step backwards (and not just for 64-bit computing, but
also for CPU speed, RAM, disk space (especially where SSDs are used instead
of the traditional HDDs) and LCD pixel counts

I like this fact. I think this will push Linux. Code on slow machines,
and on "normal" machines, the system will kick-ass! :D

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: F12: where did window properties go?

[Kevin Kofler]

Rahul Sundaram wrote:
> control-center-extra isn't there in upstream releases of GNOME afaik.

So what? Neither is Firefox and it's installed by default in our GNOME spin 
and many other GNOME-based distros.

Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Review request...

[Kevin Kofler]

Josh Boyer wrote:

> On Thu, Nov 19, 2009 at 02:23:22AM +0100, Kevin Kofler wrote:
>>Michael Schwendt wrote:
>>> Many packagers don't know that maintaining a proper spec %changelog for
>>> relevant spec file changes and %release bumps are considered important
>>> during review already. Others add meaningless/dummy %changelog entries
>>> even in Fedora cvs.
>>
>>But that's a people issue that needs to be solved, not papered over in the
>>name of "being nice".
>>
>>Sadly, "incompetence" as in unfamiliarity with guidelines which are
>>assumed to be prerequisites for proper packaging is growing in our ranks
>>(both from new packagers and from people who ought to know better),
>>something needs to be done about it.
> 
> Such as?

* Such as the very issue Michael Schwendt was pointing out (see quote).
* Such as continuous accidental upgrade path breakage due to widespread 
unfamiliarity with Release/disttag handling (e.g. I keep having to explain 
why and when to use -1.fc12.1 style versioning).
* Such as the assorted packaging mistakes which are caught by people 
watching the commits list and pointed out on this list (with the offending 
maintainer CCed).
etc.

Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Security policy oversight needed?

[Kevin Kofler]

Gregory Maxwell wrote:
> The time configuration policy is actually a fantastic example of this:
> After it was pointed out that any user could change the time
> willy-nilly the complaint was disregarded and denied by many because
> the dialog *did* ask for a password, as would be the classic unix
> security model expectation. Except… it was asking for the *users*
> password rather than a root password— so if you happen to know both
> (or if they are the same) you could test it and fail to realize that
> it was violating the long-standing expectation.

FWIW, upstream KDE requires root authentication to set the current time, and 
in fact one usage (the one usage? I haven't found others so far) of KAuth in 
KDE 4.4 will be to use PolicyKit to prompt for the root password (KDE 4.3 
uses kdesu there). So now we also have inconsistent system policies, with 
one tool explicitly prompting for root and another one not doing it. :-(

Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

[Ikem Krueger]

> IMHO, the right solution is to make the 64-bit edition the default download
> and to work on making the error message people get when trying to install it
> on a 32-bit machine nicer: "We're sorry, but your computer is too old to
> install this 64-bit version of Fedora. Please download the legacy 32-bit
> edition instead."

That would be an aweful first experience. Imagine her thoughts: "Oh. I
made something wrong.. Maybe it's nothing for me.."

I suggest to let it as it is and check the system (if 64bit or 32bit)
when it is running.

Maybe then a little popup comes up with something like:

"You're pc could be run faster, if you upgrade this operating system
to the 64bit version of it. You can download them here if you like:
[Link]"

Even better would be:

"You're pc could be run faster, if you upgrade this operating system
to the 64bit version of it. You can do so by clicking here: [Button]"

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: F12: where did window properties go?

[Rahul Sundaram]

On 11/19/2009 07:18 AM, Kevin Kofler wrote:
> Rahul Sundaram wrote:
>> What distribution they go to will do the same thing, next cycle
>> considering this will be a upstream change.
> 
> They could just install the control-center-extra package by default. We 
> (well, our GNOME spin) could, too.

control-center-extra isn't there in upstream releases of GNOME afaik.

Rahul

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

[Rahul Sundaram]

On 11/19/2009 07:26 AM, Kevin Kofler wrote:
> King InuYasha wrote:
>> In any case, 32-bit shouldn't be considered legacy until every type of
>> computer sold is 64-bit. And the fact is, that isn't true.
> 
> It already basically was before netbooks came and turned the clock back. :-(

Regardless of your take on that, it is now a very very popular segment
and many users are going to run Fedora on those systems (ie) 32-bit is
getting a whole new life all over again. We cannot call them legacy or
side line them.

My not too old laptop is 32-bit only (Dell D420 if you care).

Rahul

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

[Kevin Kofler]

King InuYasha wrote:
> In any case, 32-bit shouldn't be considered legacy until every type of
> computer sold is 64-bit. And the fact is, that isn't true.

It already basically was before netbooks came and turned the clock back. :-(

> Netbooks are entirely 32-bit currently

Yeah, they're a huge step backwards (and not just for 64-bit computing, but 
also for CPU speed, RAM, disk space (especially where SSDs are used instead 
of the traditional HDDs) and LCD pixel counts (as a result of compactness, 
but this breaks many apps who have been assuming that the 640×480 era was 
long past and that 800×600 was the bare minimum – the original plan for KDE 
4 was even to require 1024×768!)).

> and a majority of low end desktops are still 32-bit only.

Huh? What low-end desktops? All the current desktop CPUs are 64-bit. Even 
the desktop versions (not the netbook versions) of the Atom are. There may 
be some mini-desktops with netbook CPUs, but those aren't really the 
standard desktops.

Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Matthew Miller]

On Wed, Nov 18, 2009 at 11:45:14AM -0800, Dan Williams wrote:
> But that's not right because those files aren't config files.  Instead,
> you drop "local authority" files in /var/lib/polkit-1/localauthority/
> that override those permissions on a site-by-site basis for your
> specific use-case, irregardless of what the defaults are.

The config files live in /var? 

Really.




-- 
Matthew Miller 
Senior Systems Architect 
Cyberinfrastructure Labs / Instructional & Research Computing
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: F12: where did window properties go?

[Kevin Kofler]

Rahul Sundaram wrote:
> What distribution they go to will do the same thing, next cycle
> considering this will be a upstream change.

They could just install the control-center-extra package by default. We 
(well, our GNOME spin) could, too.

Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

[King InuYasha]

On Wed, Nov 18, 2009 at 7:27 PM, Kevin Kofler wrote:

> Gregory Maxwell wrote:
> > I noticed that http://fedoraproject.org/get-fedora appears to be
> > strongly promoting i386 Fedora over x86_64. Is this intentional or an
> > oversight?
>
> This is, sadly, intentional. I and others have been complaining about this
> for months, we got ignored, all in the names of making things work for
> people who are not smart enough to figure out whether their computer is 64-
> bit or not. The argument that almost all new non-netbook machines are
> 64-bit
> anyway also got ignored.
>
> IMHO, the right solution is to make the 64-bit edition the default download
> and to work on making the error message people get when trying to install
> it
> on a 32-bit machine nicer: "We're sorry, but your computer is too old to
> install this 64-bit version of Fedora. Please download the legacy 32-bit
> edition instead."
>
>Kevin Kofler
>
>
Is it right to call 32-bit legacy though? As it is, the Intel architecture
doesn't seem like a true 64-bit architecture. It seems more like it extends
the 32-bit arch and wraps 64-bitness around it.

In any case, 32-bit shouldn't be considered legacy until every type of
computer sold is 64-bit. And the fact is, that isn't true. Netbooks are
entirely 32-bit currently, and a majority of low end desktops are still
32-bit only.
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Can't seem to make tag

[Neal Becker]

Something seems strange here with libotf.  I want to push 0.9.9-3 for F12.  
I went into my F-12 subdir and did the usual
make tag build

ERROR: Tag libotf-0_9_9-3_fc12 has been already created.

OK, I bumped the tag.

cvs tag  -c libotf-0_9_9-3_fc12_1
ERROR: Tag libotf-0_9_9-3_fc12_1 has been already created.

That's strange.  OK, bump tag again:
cvs tag  -c libotf-0_9_9-3_fc12_2
ERROR: Tag libotf-0_9_9-3_fc12_2 has been already created.

Now I'm really confused.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Review request...

[Josh Boyer]

On Thu, Nov 19, 2009 at 02:23:22AM +0100, Kevin Kofler wrote:
>Michael Schwendt wrote:
>> Many packagers don't know that maintaining a proper spec %changelog for
>> relevant spec file changes and %release bumps are considered important
>> during review already. Others add meaningless/dummy %changelog entries
>> even in Fedora cvs.
>
>But that's a people issue that needs to be solved, not papered over in the 
>name of "being nice".
>
>Sadly, "incompetence" as in unfamiliarity with guidelines which are assumed 
>to be prerequisites for proper packaging is growing in our ranks (both from 
>new packagers and from people who ought to know better), something needs to 
>be done about it.

Such as?

josh

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Head-up - new firefox in rawhide

[Kevin Kofler]

Martin Stransky wrote:
> Mozilla decided to merge all include directories to one (mozbz#398573)
> and stop shipping stable/unstable packages.

Does this mean the API will finally be kept stable? Or is it now even harder 
to figure out what needs rebuilding and what not?

Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Question about tagging

[Alex Lancaster]

> "-" == Rick L Vinyard,  writes:

-> Michael Schwendt wrote:
>> On Wed, 18 Nov 2009 08:53:16 -0700, Jr. wrote:
>
>> Tom \"spot\" Callaway wrote:
>> > On 11/18/2009 10:29 AM, Rick L. Vinyard, Jr. wrote:
>> >> Shouldn't I be getting f13 tags with "make tag"?
>>> >
>>> > If you run: cvs update -d in the top level checkout directory, you
>>> will.  > ;)
>>> >
>>> 
>>> I did. What I generally run is 'cvs -PAd'
>>> 
>>> I even removed the devel directory and re-checked it out by running
>>> 'cvs -PAd' in the top level directory.
>> 
>> What about the "common" directory? That's the important one, one
>> level above "devel".
>> 
>> $ cat cairomm/common/branches|grep devel
>> devel:dist-f13:.fc13:fedora:13
>> 
>> -- fedora-devel-list mailing list fedora-devel-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>> 

> That was it. Thanks.

This has bitten me (and other users judging from the earlier reports
here) before.  It would be better if "make tag" was to check that the
"common" directory that it checked for "branches" was up to date
*before* allowing "make tag" to proceed.

This is the kind of thing that is very easy to overlook when you are
away from maintaining packages for a while and should be automated.

Which component would be best to open a trac ticket for this
functionality against?

Alex

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

[Kevin Kofler]

Gregory Maxwell wrote:
> I noticed that http://fedoraproject.org/get-fedora appears to be
> strongly promoting i386 Fedora over x86_64. Is this intentional or an
> oversight?

This is, sadly, intentional. I and others have been complaining about this 
for months, we got ignored, all in the names of making things work for 
people who are not smart enough to figure out whether their computer is 64-
bit or not. The argument that almost all new non-netbook machines are 64-bit 
anyway also got ignored.

IMHO, the right solution is to make the 64-bit edition the default download 
and to work on making the error message people get when trying to install it 
on a 32-bit machine nicer: "We're sorry, but your computer is too old to 
install this 64-bit version of Fedora. Please download the legacy 32-bit 
edition instead."

Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Review request...

[Kevin Kofler]

Michael Schwendt wrote:
> Many packagers don't know that maintaining a proper spec %changelog for
> relevant spec file changes and %release bumps are considered important
> during review already. Others add meaningless/dummy %changelog entries
> even in Fedora cvs.

But that's a people issue that needs to be solved, not papered over in the 
name of "being nice".

Sadly, "incompetence" as in unfamiliarity with guidelines which are assumed 
to be prerequisites for proper packaging is growing in our ranks (both from 
new packagers and from people who ought to know better), something needs to 
be done about it.

Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Todd Zullinger]

[At the risk of letting this get lost in the shuffle of this
thread...]

Seth Vidal wrote:
> If there are pkgs which run daemons which are defaulting to ON when
> installed or on next reboot - then we should be auditing those pkgs.
> Last I checked we default to OFF and that should continue to be the
> case.

I happened to install func the other day on several Fedora and CentOS
boxes and was surprised that both services defaulted to on.

Trying this on clean Fedora 12 box I found that a combination of a
poor init script and the presence of redhat-lsb had prevented the
services from being configured as the packages intend them to be:

$ sudo yum install certmaster
...
$ sudo chkconfig --list certmaster
service certmaster supports chkconfig, but is not referenced in any runlevel 
(run 'chkconfig --add certmaster')

The problem is that %post checks first for the presence of
/usr/lib/lsb/install_initd, which redhat-lsb provides:

# for suse
if [ -x /usr/lib/lsb/install_initd ]; then
  /usr/lib/lsb/install_initd /etc/init.d/funcd
# for red hat distros
elif [ -x /sbin/chkconfig ]; then
  /sbin/chkconfig --add funcd
...
fi

Fortunately, neither funcd nor certmaster provide critical things
like, say, remote control of a system. ;)

-- 
ToddOpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~
We are free not because we claim freedom, but because we PRACTICE it.
-- William Faulkner



pgpVpoNRdVP5a.pgp
Description: PGP signature
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Jeff Garzik]

On 11/18/2009 07:45 PM, Mike McGrath wrote:

Stick with the facts, be clear about what you're
trying to accomplish (changing it back in F13?  Changing it back in F12?
Setting a policy so stuff like this doesn't happen again?)



1) We should recognize this new policy departs from decades of Unix and 
Linux sysadmin experience.


2) F12 policy should be reverted to F11, ASAP.  Possibly with a CVE.

3) Due to #1, F13+ should not deviate from the decades-old default.

4) Release notes should explain new [and after step #2, optional] policy 
in detail, including how to turn it off again.  Seth's laudable write-up 
efforts should not have been necessary -- that info should be prepared.


5) The people who want this new security policy should add an opt-in 
checkbox in Anaconda or firstboot.


Jeff



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Security policy oversight needed?

[Gregory Maxwell]

On Wed, Nov 18, 2009 at 7:37 PM, Mike McGrath  wrote:
> I think that's too subjective though.  I'd be more in favor of a simple,

How is this subjective? At one time it was the norm that you had to
justify a SUID 0 binary. Packagekit is basically allowing the same
thing through other means. It should be subject to at least the same
scrutiny.

> broad view of what the user should be able to do without root.  It's
> possible "install packages" would be on that list, it's possible not.
> That way packages could ask themselves "does this break the policy?"  If
> it doesn't, great.  If it does, time for a bug report.
>
> Better then a review process because then everyone would generally know
> what to expect.

Some kind of review and disclosure should still be required because
security holes can be astonishingly difficult to spot as bugs, yet
utterly trivial to exploit.

The time configuration policy is actually a fantastic example of this:
After it was pointed out that any user could change the time
willy-nilly the complaint was disregarded and denied by many because
the dialog *did* ask for a password, as would be the classic unix
security model expectation. Except… it was asking for the *users*
password rather than a root password— so if you happen to know both
(or if they are the same) you could test it and fail to realize that
it was violating the long-standing expectation.

There is also the significant possibility of policy interaction. A
sufficiently general policy (i.e. one which isn't just the policykit
policy) could possibly permit configurations which are acceptable in
isolation but which are hazardous in practice.

E.g. perhaps one policy permits the install of packages from
pre-configured repos and another policy permits the user to add repos
(to make it easy to navigate them in the package management
interface).

(Not the adding packages from existing repos isn't already a terrible
security hole: Unless you have very specific rules about the default
configuration of packages in the repo it's likely that some of the
packages will violate the security expectations when installed)

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: RFC: Btrfs snapshots feature for F13

[Kevin Kofler]

Chris Ball wrote:
> Creating a new snapshot is unprivileged

Huh? Isn't that a license for any user to waste massive amounts of disk 
space, ignoring any per-user quota? Whole file system operations must be 
root only!

Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Security policy oversight needed?

[Chris Adams]

Once upon a time, Mike McGrath  said:
> I think that's too subjective though.

What is subjective about "allowing unprivileged to do things that
previously only root could do"?

> I'd be more in favor of a simple,
> broad view of what the user should be able to do without root.  It's
> possible "install packages" would be on that list, it's possible not.
> That way packages could ask themselves "does this break the policy?"  If
> it doesn't, great.  If it does, time for a bug report.

There have been bug reports, but they get closed by the maintainers as
NOTABUG, so that procedure is obviously not working.

-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Benjamin Kreuter]

On Wednesday 18 November 2009 12:48:28 pm Rahul Sundaram wrote:
> .. if the packages are signed and from a signed repository. So, you left
> out the important part. Explain why this is a problem in a bit more
> detail.

Not every Fedora installation will fall neatly into "single user" or "actively 
managed" categories.  I might be managing half a dozen machines in some office 
at my university, and had I not known about this new, unprecedented feature, I 
might come in one day and discover that everyone is running a completely 
different system -- even though none of them have the root password!  I also 
cannot claim that I am familiar with all of the thousands of packages in the 
Fedora repositories, and would rather not come in one day and have a user ask 
me for help after having installed dozens of unfamiliar packages after a few 
weeks of using the system.

I do not feel this is a terribly contrived example...

-- Ben



-- 
Message sent on: Wed Nov 18 20:00:53 EST 2009


signature.asc
Description: This is a digitally signed message part.
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Bastien Nocera]

On Wed, 2009-11-18 at 13:50 -0500, Tony Nelson wrote:
> On 09-11-18 13:44:43, nodata wrote:
> > Am 2009-11-18 19:16, schrieb Bruno Wolff III:
> > > On Wed, Nov 18, 2009 at 17:45:26 +,
> > >Bastien Nocera  wrote:
> > >>
> > >> Once we get the new user management stuff into F13 [1], we'd
> > >> probably tighten that rule so that only admins are given the 
> > >> option, or all users but with the need to authenticate as an 
> > >> admin.
> > >
> > > This seems pretty reasonable.
> > 
> > I don't like the way Fedora is going with this: digging out something 
> > that works and saying "we'll replace it later" makes no sense. Make 
> > it work now, or *keep it in*.
> 
> Fedora has always been this way.  Have you tried to use sound or video 
> in the past few releases?  I think it's called "creative destruction".

And I'm sure the passive-aggressive in you filed bugs.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Jeff Spaleta]

On Wed, Nov 18, 2009 at 3:52 PM, Eric Christensen
 wrote:
> Maybe.  I mean removing (or not installing) PK is a snap with kickstart.
> I haven't visited my kickstart in a while so...  :)

Whick PK are you talking about... packagekit or policykit?  PackageKit
is probably what you mean given the context..but PK as a shorthand can
mean either.

And I think you missed my point. As we are learning..the hard way...
sysadmins and spin developers can and should be encouraged to generate
site specific policykit rules as part of hardening/softening ALL
policykit enabled applications. You we really won't be able to rip out
all the stuff using policykit.  We're gonna have to digest the fact
that policykit is there and start dealing with it in our setups and we
are going to need some hand holding so we can do it effectively.
PackageKit's policy is just the beginning of the learning curve here.
It may not be server relevant as an application.. but the underlying
issue about checking and configuring PolicyKit settings will be server
relevant and unavoidable at some point.


-jef

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Jeff Garzik]

On 11/18/2009 07:52 PM, Eric Christensen wrote:

I guess the big thing, to me, is that this vulnerability wasn't
presented, documented, or talked about and it is the opposite policy to
what most (all?) SYSADMINS would expect.  If you don't know to fix it
then you are pwned.


Bingo.  That is the crux of the dilemma.

Jeff


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Bill Nottingham]

Jeff Garzik (jgar...@pobox.com) said: 
> >>This sounds like a tacit admission that the default install for
> >>servers is bloody stupid (== same as desktop), unless the admin
> >>REMOVES packages we helpfully installed on the server system.
> >
> >PackageKit has only ever been included in destkop package groups.
> >While these groups are enabled by default, they are with the caveat of:
> >
> >"The default installation of Fedora includes a set of software
> >applicable for general internet usage."
> 
> Completely irrelevant, because...  setroubleshoot and other useful
> server tools REQUIRE PackageKit.

You mean the tools which *also* aren't ever installed except in
desktop groups?

Bill

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Jeff Garzik]

On 11/18/2009 07:43 PM, Bill Nottingham wrote:

Jeff Garzik (jgar...@pobox.com) said:

This sounds like a tacit admission that the default install for
servers is bloody stupid (== same as desktop), unless the admin
REMOVES packages we helpfully installed on the server system.


PackageKit has only ever been included in destkop package groups.
While these groups are enabled by default, they are with the caveat of:

"The default installation of Fedora includes a set of software
applicable for general internet usage."


Completely irrelevant, because...  setroubleshoot and other useful 
server tools REQUIRE PackageKit.




(This was all easily verifyable, if you'd prefer to look, instead
of rant.)


Pot, meet kettle.  Run a dependency query next time.

Jeff



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Eric Christensen]

On Wed, 2009-11-18 at 15:43 -0900, Jeff Spaleta wrote:
> On Wed, Nov 18, 2009 at 3:35 PM, Eric Christensen
>  wrote:
> > PackageKit is something right there on the desktop that, to its credit,
> > needs little knowledge to use whereas many of your attack vectors noted
> > above are generally fixed in my shop by use of a kickstart and securing
> > the box from physical access and require a higher skill to perform.
> 
> So can't you harden this with a kickstart file line like you do in
> your other hardening steps in your shop? I think to point Bill is
> trying to make is that there are of a number of other settings that
> need to be hardened and that this choice is just one of many choices
> associated with security associated with a console user.  Console user
> security is already a leaky ship and PK is just one more hole.
> 
> -jef
> 

Maybe.  I mean removing (or not installing) PK is a snap with kickstart.
I haven't visited my kickstart in a while so...  :)

I guess the big thing, to me, is that this vulnerability wasn't
presented, documented, or talked about and it is the opposite policy to
what most (all?) SYSADMINS would expect.  If you don't know to fix it
then you are pwned.  Most of the hardening guides that I've read or have
contributed to assumed that the operating system wouldn't allow this
kind of behavior by default and thus doesn't really address it.  I know
the hardening guide for RHEL from the NSA talks about setting up sudo
and how to use it but doesn't talk about securing pup, IIRC.

--Eric


signature.asc
Description: This is a digitally signed message part
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Bill Nottingham]

Eric Christensen (e...@christensenplace.us) said: 
> > It's a behavior change, for sure. For people who want to lock down their
> > systems, it's a default they will need to be able to change, and they
> > should have been able to discover it through the normal mechanisms for
> > that. (i.e., the release notes.). It likely should have been discussed
> > when it was introduced - it's obviously not something that's applicable
> > to all usage cases for the OS.
>
> You are assuming that the users have physical access to the box and also
> know how to get a root shell and that the box hasn't been hardened
> (before the PK vulnerability was known).

Sure, I said 'out of the box'. Out of the box none of those other
hardening steps are done either, which is why if this is a policy
that we want, it should be documented as a hardening step that can
be taken.

Bill

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Mike McGrath]

On Wed, 18 Nov 2009, Jeff Garzik wrote:

> On 11/18/2009 07:23 PM, Bill Nottingham wrote:
> > Jeff Garzik (jgar...@pobox.com) said:
> > > Sorry, but this default (desktop users can install pkgs without
> > > root) is just stupid.  It is antithetical to all standard security
> > > models that have come before in Fedora and other Linux
> > > distributions.
> >
> > Out of the box, a desktop user has the ability to shut down the machine.
> > This gives them the ability, out of the box, to:
> > - DoS everyone on it
> > - get a root shell
> > -- install whatever they want
> > -- put viruses on
> > - hell, slap in a livecd or USB key and reinstall the box
>
> How is any of that justification for lowering the security bar to zero?
>

We haven't lowered the security bar to zero.  We don't mount home dirs
noexec by default[1] so on the security level we're only talking about
security vulnerabilities to suid packages.  All of which could be
installed via a reboot and grub changes *and* would require a
vulnerability in that package, something we're very quick to fix.  Though
keeping N and N-1 versions on the mirror is a security vulnerability as
the old version could always be pulled in.

> All of those you list are more technically complex than the current F12
> behavior -- letting the kids or guests click a button.
>

It also lets them keep the system up to date, there's an argument to be
made here that this aspect is more secure.

> IFF this feature was listed as a question in firstboot, and
> IFF this feature was explained in detail in release notes, then there would
> have been no problem at all...
>

I tend to agree with this.  I believe this is similar to how ubuntu does
it with some sort of opt-in.

> You also omitted the case where admins of servers upgrade into a less secure
> policy.  PackageKit presence does not imply desktop user.
>

I think you'd find your arguments would be better received if you weren't
so dramatic about it.  Stick with the facts, be clear about what you're
trying to accomplish (changing it back in F13?  Changing it back in F12?
Setting a policy so stuff like this doesn't happen again?)

-Mike

[1]  Talking about something as simple as rpm2cpio here

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Security policy oversight needed?

[Jeff Garzik]

On 11/18/2009 07:37 PM, Mike McGrath wrote:

I think that's too subjective though.  I'd be more in favor of a simple,
broad view of what the user should be able to do without root.  It's
possible "install packages" would be on that list, it's possible not.
That way packages could ask themselves "does this break the policy?"  If
it doesn't, great.  If it does, time for a bug report.

Better then a review process because then everyone would generally know
what to expect.


Agreed, that makes more sense and is more scalable.

Jeff



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Jeff Spaleta]

On Wed, Nov 18, 2009 at 3:35 PM, Eric Christensen
 wrote:
> PackageKit is something right there on the desktop that, to its credit,
> needs little knowledge to use whereas many of your attack vectors noted
> above are generally fixed in my shop by use of a kickstart and securing
> the box from physical access and require a higher skill to perform.

So can't you harden this with a kickstart file line like you do in
your other hardening steps in your shop? I think to point Bill is
trying to make is that there are of a number of other settings that
need to be hardened and that this choice is just one of many choices
associated with security associated with a console user.  Console user
security is already a leaky ship and PK is just one more hole.

-jef

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Jeff Garzik]

On 11/18/2009 07:37 PM, Colin Walters wrote:

On Wed, Nov 18, 2009 at 7:36 PM, Jeff Garzik  wrote:


And it ignores that remote exploits are now much easier, because remote
non-root exploit + package install == remote root exploit.


No, the uid needs to have logged in through a physical console.



See references in multiple mails to firefox, pidgin, and any number of 
other example applications run by a uid logged in through a physical 
console.


Web browsers -- especially with bin-only flash -- are the most likely 
vector for remote exploits these days.  Far more so than any system daemon.


There are Real Good(tm) reasons why Firefox complains, if your Flash 
plug-in is out of date, even on Linux...


Jeff



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Bill Nottingham]

Jeff Garzik (jgar...@pobox.com) said: 
> This sounds like a tacit admission that the default install for
> servers is bloody stupid (== same as desktop), unless the admin
> REMOVES packages we helpfully installed on the server system.

PackageKit has only ever been included in destkop package groups.
While these groups are enabled by default, they are with the caveat of:

"The default installation of Fedora includes a set of software
applicable for general internet usage."

(This was all easily verifyable, if you'd prefer to look, instead
of rant.)

Bill

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Security policy oversight needed?

[Michael Stahnke]

On Wed, Nov 18, 2009 at 6:37 PM, Mike McGrath  wrote:
> On Wed, 18 Nov 2009, Simo Sorce wrote:
>
>> On Wed, 2009-11-18 at 17:58 -0600, Chris Adams wrote:
>> > Any package (whether new or an update) that adds/changes PolicyKit,
>> > consolehelper, or PAM configuration, and anything that installs new
>> > setuid/setgid executables, should require some additional third-party
>> > review.  Any significant changes that passes review should require some
>> > minimum amount of advance notice and documentation on how to revert
>> > (preferably in some common easy-to-find place in the wiki).
>> >
>> > Is this feasible?
>>
>> Looks like a very good idea to me.
>>
>
> I think that's too subjective though.  I'd be more in favor of a simple,
> broad view of what the user should be able to do without root.  It's
> possible "install packages" would be on that list, it's possible not.
> That way packages could ask themselves "does this break the policy?"  If
> it doesn't, great.  If it does, time for a bug report.
>
> Better then a review process because then everyone would generally know
> what to expect.
>
>        -Mike
>
I agree. I think that's easier rather than trying to understand the
specifics of each package.

stahnma

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Colin Walters]

On Wed, Nov 18, 2009 at 7:36 PM, Jeff Garzik  wrote:

> And it ignores that remote exploits are now much easier, because remote
> non-root exploit + package install == remote root exploit.

No, the uid needs to have logged in through a physical console.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Security policy oversight needed?

[Mike McGrath]

On Wed, 18 Nov 2009, Simo Sorce wrote:

> On Wed, 2009-11-18 at 17:58 -0600, Chris Adams wrote:
> > Any package (whether new or an update) that adds/changes PolicyKit,
> > consolehelper, or PAM configuration, and anything that installs new
> > setuid/setgid executables, should require some additional third-party
> > review.  Any significant changes that passes review should require some
> > minimum amount of advance notice and documentation on how to revert
> > (preferably in some common easy-to-find place in the wiki).
> >
> > Is this feasible?
>
> Looks like a very good idea to me.
>

I think that's too subjective though.  I'd be more in favor of a simple,
broad view of what the user should be able to do without root.  It's
possible "install packages" would be on that list, it's possible not.
That way packages could ask themselves "does this break the policy?"  If
it doesn't, great.  If it does, time for a bug report.

Better then a review process because then everyone would generally know
what to expect.

-Mike

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Jeff Garzik]

On 11/18/2009 07:34 PM, Jeff Garzik wrote:

On 11/18/2009 07:23 PM, Bill Nottingham wrote:

Jeff Garzik (jgar...@pobox.com) said:

Sorry, but this default (desktop users can install pkgs without
root) is just stupid. It is antithetical to all standard security
models that have come before in Fedora and other Linux
distributions.


Out of the box, a desktop user has the ability to shut down the machine.
This gives them the ability, out of the box, to:
- DoS everyone on it
- get a root shell
-- install whatever they want
-- put viruses on
- hell, slap in a livecd or USB key and reinstall the box


How is any of that justification for lowering the security bar to zero?

All of those you list are more technically complex than the current F12
behavior -- letting the kids or guests click a button.


And it ignores that remote exploits are now much easier, because remote 
non-root exploit + package install == remote root exploit.


Jeff



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Eric Christensen]

On Wed, 2009-11-18 at 19:23 -0500, Bill Nottingham wrote:
> Jeff Garzik (jgar...@pobox.com) said: 
> > Sorry, but this default (desktop users can install pkgs without
> > root) is just stupid.  It is antithetical to all standard security
> > models that have come before in Fedora and other Linux
> > distributions.
> 
> Out of the box, a desktop user has the ability to shut down the machine.
> This gives them the ability, out of the box, to:
> - DoS everyone on it
> - get a root shell
> -- install whatever they want
> -- put viruses on
> - hell, slap in a livecd or USB key and reinstall the box
> 
> It's a behavior change, for sure. For people who want to lock down their
> systems, it's a default they will need to be able to change, and they
> should have been able to discover it through the normal mechanisms for
> that. (i.e., the release notes.). It likely should have been discussed
> when it was introduced - it's obviously not something that's applicable
> to all usage cases for the OS.
> 
> But really, given that users out of the box can do *far far worse*, I'm
> not seeing the 'shameful', 'antithetical', OMG THE SKY IS FALLING AND
> YOU ALL SHOULD BE DRAWN AND QUARTERED sort of angst. Maybe people are
> tired of bagging tea and want new things to be outraged about.
> 
> Bill
> 

Bill,
You are assuming that the users have physical access to the box and also
know how to get a root shell and that the box hasn't been hardened
(before the PK vulnerability was known).

PackageKit is something right there on the desktop that, to its credit,
needs little knowledge to use whereas many of your attack vectors noted
above are generally fixed in my shop by use of a kickstart and securing
the box from physical access and require a higher skill to perform.

I'm not saying this new "functionality" in PK is necessarily bad but it
should have been easily ENABLED (not by default) by an admin with root
privileges.

Of course, in my thought process, now, PK should probably not be
installed on systems where users shouldn't have unrestricted access to
the repo.

--Eric


signature.asc
Description: This is a digitally signed message part
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Jeff Garzik]

On 11/18/2009 07:23 PM, Bill Nottingham wrote:

Jeff Garzik (jgar...@pobox.com) said:

Sorry, but this default (desktop users can install pkgs without
root) is just stupid.  It is antithetical to all standard security
models that have come before in Fedora and other Linux
distributions.


Out of the box, a desktop user has the ability to shut down the machine.
This gives them the ability, out of the box, to:
- DoS everyone on it
- get a root shell
-- install whatever they want
-- put viruses on
- hell, slap in a livecd or USB key and reinstall the box


How is any of that justification for lowering the security bar to zero?

All of those you list are more technically complex than the current F12 
behavior -- letting the kids or guests click a button.


IFF this feature was listed as a question in firstboot, and
IFF this feature was explained in detail in release notes, then there 
would have been no problem at all...


You also omitted the case where admins of servers upgrade into a less 
secure policy.  PackageKit presence does not imply desktop user.


Jeff


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Jeff Spaleta]

On Wed, Nov 18, 2009 at 3:23 PM, Bill Nottingham  wrote:
> But really, given that users out of the box can do *far far worse*, I'm
> not seeing the 'shameful', 'antithetical', OMG THE SKY IS FALLING AND
> YOU ALL SHOULD BE DRAWN AND QUARTERED sort of angst. Maybe people are
> tired of bagging tea and want new things to be outraged about.

I know I'm tired of bagging tea.  Luckily for me there's a new bubble
tea shop in town with free wifi.  I can enjoy bagless tea all day long
and still get work done.

-jef"needs a bubble tea protest t-shirt"spaleta

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Local users get to play root?

[Bill Nottingham]

Jeff Garzik (jgar...@pobox.com) said: 
> Sorry, but this default (desktop users can install pkgs without
> root) is just stupid.  It is antithetical to all standard security
> models that have come before in Fedora and other Linux
> distributions.

Out of the box, a desktop user has the ability to shut down the machine.
This gives them the ability, out of the box, to:
- DoS everyone on it
- get a root shell
-- install whatever they want
-- put viruses on
- hell, slap in a livecd or USB key and reinstall the box

It's a behavior change, for sure. For people who want to lock down their
systems, it's a default they will need to be able to change, and they
should have been able to discover it through the normal mechanisms for
that. (i.e., the release notes.). It likely should have been discussed
when it was introduced - it's obviously not something that's applicable
to all usage cases for the OS.

But really, given that users out of the box can do *far far worse*, I'm
not seeing the 'shameful', 'antithetical', OMG THE SKY IS FALLING AND
YOU ALL SHOULD BE DRAWN AND QUARTERED sort of angst. Maybe people are
tired of bagging tea and want new things to be outraged about.

Bill

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Security policy oversight needed?

[Simo Sorce]

On Wed, 2009-11-18 at 17:58 -0600, Chris Adams wrote:
> Any package (whether new or an update) that adds/changes PolicyKit,
> consolehelper, or PAM configuration, and anything that installs new
> setuid/setgid executables, should require some additional third-party
> review.  Any significant changes that passes review should require some
> minimum amount of advance notice and documentation on how to revert
> (preferably in some common easy-to-find place in the wiki).
> 
> Is this feasible?

Looks like a very good idea to me.

> Who needs to look at this?

Fesco ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: RFC: Btrfs snapshots feature for F13

[Bill McGonigle]

On 11/16/2009 07:55 PM, Chris Ball wrote:
> It'd be great to get feedback on whether this is the right idea

You might look into how the nexenta guys implemented this:
  http://www.nexenta.org/os/TransactionalZFSUpgrades
to see if they have some thoughts worth borrowing.

With the caveat that I haven't yet created a btrfs (seriously waiting on
a Seagate RMA), I think most of the complaints on this thread are due to
thinking of filesystems in old terms, due to limitations of old storage
concepts.

To do this right probably requires the careful use of subvolumes.  One
for rpm, one for logs, one for each package installed, one for each
user's home, etc.  From rpm you can know what needs rolling back.  This
probably implies foo-var, foo-etc, foo-log, foo-share, etc, which is
inefficient, so maybe some refinement is needed there as well.

-Bill

-- 
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.603.448.4440
Email, IM, VOIP: b...@bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: F12: where did window properties go?

[Rahul Sundaram]

On 11/19/2009 05:33 AM, Tom Lane wrote:
> 
> Wow, so we're going to seriously piss off some significant fraction
> of the userbase in order to save 59k.  Personally, I don't care about
> most of the random UI changes that get thrown in during every Fedora
> cycle, but lack of focus follows mouse would get me to move to some
> other distro.  I wonder how many people will abandon Fedora without
> bothering to read the fine print in the release notes.

What distribution they go to will do the same thing, next cycle
considering this will be a upstream change. I think, we have bigger
problems to worry about.

Rahul

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list