review request for schroot package: security expertise needed
by Zach Carter
Hi:
I'm trying to get this package thru the review process. Some helpful people
have already done reviews, and its pretty much ready to go, but there are some
security issues that really need to be looked at by a security subject matter
expert.
In particular, there are some setuid binaries and a pam configuration file that
need to be reviewed from a security perspective.
Is anyone on the list willing to take a look?
https://bugzilla.redhat.com/show_bug.cgi?id=447368
thanks!
-Zach
P.S. - I am also looking for a sponsor
"
Description:
schroot allows users to execute commands or interactive shells in
different chroots. Any number of named chroots may be created, and
access permissions given to each, including root access for normal
users, on a per-user or per-group basis. Additionally, schroot can
switch to a different user in the chroot, using PAM for
authentication and authorisation. All operations are logged for
security.
"
15 years
Re: Independent Fedora bug tracker
by Bill Crawford
On Monday 27 April 2009 15:19:44 Matej Cepl wrote:
> Bill Crawford píše v So 25. 04. 2009 v 15:46 +0100:
> > Sorry, forgot screenshot (can't remember if the list allows them; you
> > should see it on the Cc: anyway.
>
> Do you have switched off Javascript or something (image looks kind of
> non-standard) ... I have in my Firefox AJAXy solution ... full list is
> downloaded only when change is required.
Oh, I'm looking at "create new bug" and you're looking at an existing
one, ... :-$
15 years
Re: Independent Fedora bug tracker
by Bill Crawford
On Monday 27 April 2009 15:19:44 Matej Cepl wrote:
> Bill Crawford píše v So 25. 04. 2009 v 15:46 +0100:
> > Sorry, forgot screenshot (can't remember if the list allows them; you
> > should see it on the Cc: anyway.
>
> Do you have switched off Javascript or something (image looks kind of
> non-standard) ... I have in my Firefox AJAXy solution ... full list is
> downloaded only when change is required.
Firefox 3, Fedora 8 (yes, it's old; no, I can't update yet).
Takes a good 30 seconds just to load the page, and a second give or take to
update after selecting a new component (although I'm ascribing some of that to
Firebug, which seems to slow *everything* down).
> Matej
15 years
rawhide report: 20090427 changes
by Fedora compose checker
Compose started at Mon Apr 27 06:15:03 UTC 2009
Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 0
Broken deps for i386
----------------------------------------------------------
nssbackup-0.2-0.2.rc7.fc10.noarch requires python(abi) = 0:2.5
python-arm4-1.1-3.fc10.i386 requires libpython2.5.so.1.0
python-arm4-1.1-3.fc10.i386 requires python(abi) = 0:2.5
sems-ivr-1.1.0-5.fc10.i386 requires libpython2.5.so.1.0
sems-python-1.1.0-5.fc10.i386 requires libpython2.5.so.1.0
sems-xmlrpc2di-1.1.0-5.fc10.i386 requires libssl.so.7
Broken deps for x86_64
----------------------------------------------------------
nssbackup-0.2-0.2.rc7.fc10.noarch requires python(abi) = 0:2.5
python-arm4-1.1-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
python-arm4-1.1-3.fc10.x86_64 requires python(abi) = 0:2.5
sems-ivr-1.1.0-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
sems-python-1.1.0-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
sems-xmlrpc2di-1.1.0-5.fc10.x86_64 requires libssl.so.7()(64bit)
Broken deps for ppc
----------------------------------------------------------
fedora-ksplice-0.5-3.fc11.noarch requires ksplice
nssbackup-0.2-0.2.rc7.fc10.noarch requires python(abi) = 0:2.5
python-arm4-1.1-3.fc10.ppc requires libpython2.5.so.1.0
python-arm4-1.1-3.fc10.ppc requires python(abi) = 0:2.5
sems-ivr-1.1.0-5.fc10.ppc requires libpython2.5.so.1.0
sems-python-1.1.0-5.fc10.ppc requires libpython2.5.so.1.0
sems-xmlrpc2di-1.1.0-5.fc10.ppc requires libssl.so.7
Broken deps for ppc64
----------------------------------------------------------
cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7
fedora-ksplice-0.5-3.fc11.noarch requires ksplice
nssbackup-0.2-0.2.rc7.fc10.noarch requires python(abi) = 0:2.5
python-arm4-1.1-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
python-arm4-1.1-3.fc10.ppc64 requires python(abi) = 0:2.5
sems-ivr-1.1.0-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
sems-python-1.1.0-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
sems-xmlrpc2di-1.1.0-5.fc10.ppc64 requires libssl.so.7()(64bit)
15 years
Pulseaudio breakage in F11
by Dimi Paun
I don't particularly enjoy putting gasoline on the fire,
but I think the sound problems in Fedora needs addressing.
Ever since FC3 I did not have reliable sound on Linux.
O an bog-standard Intel 82801H (ICH8 Family). That's
maybe more like 5-6 years. I would get it to work, and
every other update it would break it.
Now, since I could not upgrade from F8 to F9 or F10 (due
to dmraid breakage in anaconda), I took the plunge and
updated my development box to F11.
SOUND STILL DOESN'T WORK!
Once again, every update breaks something. So, please
just let this sink in:
In AD2009, F11 sound doesn't work reliably on standard
hardware in Linux.
Yeah, I can redirect stream, do all sort of nifty things,
except it's a mystery every time I use Skype, Youtube,
VirtualBox or Rhythmbox is I'll get sound.
Let's stop blaming "broken software" -- PA is *crashing*
when I start VirtualBox, Skype, etc. Not the app!
If you tell me to:
* run pulseaudio -D from a terminal
* restart X
* reboot
you are missing the point. If PA crashes, it should restart
automagically and reconnet. Sound should be reliable.
Also, I don't want to hear about fixing all the bugs in PA.
It didn't happen in many years, it's not gonna happen soon.
Lennart, for the sake of all that's good, please make the
darn thing reliable. Please!
P.S. Just updated yesterday, rebooted, sound broken. Again!
Stuttering and distorsion to the point you can't hear anything;
PA using a lot of CPU, outputing bits and pieces of sound.
Spent 15min starting/restarting/configuring Skype. How much
patience can one have?!?
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
15 years
FOSS needs a central bug tracker
by Mark
Hi,
I was just reading the latest distrowatch weekly and there was an
interesting article posted there about a centralized bug tracking
system for all of foss including all of the foss operating systems
(fedora, ubuntu, mandriva.. you get the idea).
I personally find this idea very interesting and am very tempted to
put in a lot of time to get all parties together and talking about a
idea like this (top 10 major foss distributions for now i think) to
see if it would have any support in the highest ranking foss
distributions. without those this idea just might not get of the
ground so easily.
I am aware of the gigantic amount of work that will need to go into
this project but for now that's not the case, yet, for now i'm only
asking fedora and redhat (mainly the developers and leaders but i'm
interested in everyone's opinion) to read the text below (copy/paste
from DistroWatch) and then please explain if you see anything (or
nothing) in this idea? will you support it or not? do you like it? or
is it just something that needs to be forgotten as soon as possible?
Also if your an redhat employee or a fedora comuinity member helping
develop fedora please mention that in your reply. It's not always
obvious from the email address you send the reply from.
Again, don't bother (much) about the resources, time and people that
this project is going to take. That stage is way to early right now.
For now it's only asking fedora/redhat how they would act on a idea
like this.
Here is the text from DistroWatch:
FOSS needs a central bug tracker (by Jesse Smith)
It happened again today. I was using one of my favorite applications
when a familiar bug popped up its head and brought my work to a
screeching halt. Determined to rid all of humankind of this pest, I
went to the Help menu and selected "Report A Bug". Seconds later, I
was on the project's bug tracking web page. Seconds after that, I
determined that the only way for me to report this bug (to the
upstream project) was to create yet another bug tracking account.
Usually I consider myself among the lucky; I generally use Linux and
generally use one distro. Reporting bugs is relatively easy in that I
just need the one bug-tracking account with one vendor. However, there
are days, dark days, when I'm required to use other operating systems
with no central bug-tracking system. This becomes a problem after a
while. Sure, it takes very little time to set up one bug-tracking
account with one open source project. But when a person uses dozens of
open source applications across multiple operating systems, the amount
of time and the number of username/password combinations grow at an
alarming rate. As I mentioned, I usually live a sheltered, one-distro
life, but what agony distro hoppers must go through, setting up a
bug-tracking account for each and every Linux distribution they test
drive! And for those people on other operating systems, imagine
opening bug tracking accounts for GIMP, OpenOffice.org, Firefox,
FileZilla, etc, etc, in an effort to get one's voice heard!
Bug-tracking software is a wonderful tool and I applaud any software
project that uses one, but therein lies the problem: so many software
projects have this software and they all operate separately. Fedora
has one tracker, Debian another, Ubuntu another; and there are
thousands of upstream projects, many with their own trackers.
Now, let us think for a moment about these thousands of bug tracking
systems and consider the amount of duplicated effort. Not just in the
repeated bug reports when someone reports a problem to Slackware and
another person reports it to Fedora and another to Ubuntu, but also in
the effort of setting up these thousands of databases. We're talking a
lot of man/woman/admin hours, here!
I think it would be a good idea to see a grouping of this talent and
data into one place. Consider this: a project such as Debian is
already a hub for reporting bugs and making feature requests for over
20,000 open source projects. In fact, as an open source developer, I
often check the Debian bug tracker to see if anything has been
reported against my projects. Wouldn't it be reasonable if we took
this a step further and brought all of the various distributions' bug
trackers under one system? Imagine if you found a problem in any open
source project on any operating system and could report it in one
place. Just one bug tracking account for each user and developer! When
application XYZ crashes, I could go to, for example,
opensourceoops.org and report the issue, regardless of whether I'm
running a flavor of Linux, OS X or BSD. While the initial setup would
be a large effort, the reduction in duplicated work over the long term
would be fantastic. Also, it would lower the barrier to getting those
pesky bugs reported by users who don't wish to register yet another
username.
An all-in-one solution would also benefit the developers of open
source software. As I mentioned previously, I maintain a few small,
open source applications, which are packaged for various Linux
distributions and BSDs. Though I certainly don't fault the busy
package maintainers, problems and patches are very rarely forwarded
from the distributions to our upstream developers. To try to fix
everything in the upstream source, we (myself and other developers)
have had to go to each distro we know of which maintains a package of
our software and search their issue tracker for our package name. This
is tedious work. Imagine how much easier it would be to find and
integrate patches if a developer had to simply search one large issue
tracker.
I would very much like to see an open source supporter, such as Red
Hat, Canonical or Mozilla, for example, implement a large, inclusive
issue tracker. While a large investment up front, the benefits to open
source users, developers and package maintainers would be a great boon
to the community. There is some precedent for this. As mentioned
before, distributions, such as Debian, track issues for thousands of
packages. On a similar vein, web sites such as SourceForge and Google
Code already provide open source projects with a central location to
save, present and contribute. A central bug tracker could work much
the same way, providing open source developers and users with one
location to report and work on problems.
The greatest hurdle I see to adopting a central system is that people
tend to stick with what they have. For a mega issue tracker to really
be effective, most of the smaller, single-project and
distribution-specific trackers would probably have to be phased out.
People would have to be encouraged to adopt the single location
method. As an alternative, perhaps the central tracker could be set up
in such a way that it would pull issues from other sources.
Distributions and upstream projects might see the benefit of having
their trouble tickets uploaded to a central location where everyone
could see them. This would also centralize issue tracking, without the
problems of forcing people to use The One method. Change is often
difficult, especially when we're looking at so many people spread out
over the world. However, I think something needs to be done; we have
hundreds of distributions and thousands of open source projects.
Encouraging users to maintain separate accounts for each one is
cumbersome and inefficient for everyone.
15 years
Open source and diagramming survey
by chung＠engr.orst.edu
Dear open source contributors,
I am Eunyoung Chung, a Masters student working with Dr. Jensen at
Oregon State University.
We are currently doing a research project in collaboration with Dr.
Truong and Ph.D student Koji Yatani at University of Toronto. Our goal
is to understand how contributors communicate and collaborate in Open
Source Software (OSS) projects, including diagramming practices.
We are seeking volunteers for a quick survey on this topic. Any person
who is actively working on a OSS project is eligible. The survey takes
approximately 10-15 minutes, and the 5 volunteers will be picked to
receive a $30 Amazon gift certificate. Your participation is anonymous
(unless you consent to have us contact you)
Here is the survey address.
https://secure.engr.oregonstate.edu/limesurvey/58564/lang-en
We really appreciate your help!
15 years
Request to become Provenpackager
by Jussi Lehtola
Hi,
there are currently 452 open Merge Reviews (out of 1009 open review bugs
in total) open in Bugzilla. I have taken over 20 merge reviews in the
past month or two. In the majority of cases, I haven't got any replies
to the reviews even though some time has passed.
A lot of the issues could be fixed in a minute or two in CVS; as I
understand provenpackagers are allowed to do these kinds of small fixes
after having announced it a few days in advance. Doing a review is of
little avail if the maintainer doesn't respond.
I hereby proclaim my candidacy to become provenpackager.
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org
15 years
gcc-4.4 optimizations question
by Neal Becker
I saw this on gcc devel ML:
------------
On Thu, 23 Apr 2009, David Ronis wrote:
> >From the info pages it seems that the new optimizations,
> -floop-interchange, -floop-strip-mine, and -floop-block, are NOT turned
> on when -O3 is specified. Is this correct and if so, why aren't they?
Because the behavior of -O3 must not depend on whether optional libraries
are linked into GCC, and we did not decide to make PPL and CLooG required
to build GCC, so -O3 cannot enable any optimizations using optional
libraries.
Joseph S. Myers
joseph(a)codesourcery.com
-------------
Does our gcc-4.4 have these optional libs?
15 years
New packages during rawhide freeze
by Kalev Lember
Hello,
Recent rawhide composes have pulled in some .fc10 rpms which seem to
originate from Fedora 10's stable updates repo. For example, "rawhide
report: 20090422 changes" lists 10 new packages, from which I checked
first few and they all seemed to be .fc10 releases.
One of my new packages got pulled in like that too
(mingw32-libp11-0.2.4-1.fc10.noarch), even though I have a F-11 branch
and I have built it for both F-11 and devel in koji. I have also
requested the package to be added to Fedora 11 updates in Bodhi, but for
some reason it still pulled in .fc10 package instead of the correct .fc11.
Installing Fedora 10 packages in rawhide doesn't strike me as a good
idea, because they are most probably compiled using old gcc, for example.
Why does it happen? Did I (and other people who have pushed new packages
in Fedora 10 during rawhide freeze) do something wrong here?
--
Best regards,
Kalev Lember
15 years
