On Thu, Jan 21, 2010 at 02:09:57PM +, Rawhide Report wrote:
> 1:libguestfs-1.0.81-3.fc13.i686 requires /lib/libntfs-3g.so.71
Long story, but I've fixed this upstream now. It should be fixed in
Rawhide by tomorrow (not today).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http
Hello,
Has there been any plans to support running custom post-up scripts for each
interface, after "ifup " ?
Debian allows you to specify:
iface eth0 inet static
..
post-up /etc/network/if-up.d/fw.start
I'm looking for something similar for rhel/fedora.
Any ideas?
Maybe some
On Fri, Jan 22, 2010 at 11:01:37AM +0200, Pasi Kärkkäinen wrote:
> Hello,
>
> Has there been any plans to support running custom post-up scripts for each
> interface, after "ifup " ?
>
> Debian allows you to specify:
>
> iface eth0 inet static
> ..
> post-up /etc/network/if-up.d/fw.
- "Bill Nottingham" wrote:
> Jens Petersen (peter...@redhat.com) said:
> > I meant to add that the reason this came up was I was trying to work
> > out where to put yum-langpacks in comps: yum-presto being one of the
> > reference packages I searched for.
> >
> > So where can/should yum-lang
On Fri, Jan 22, 2010 at 10:13:38AM +0100, Tomasz Torcz wrote:
> On Fri, Jan 22, 2010 at 11:01:37AM +0200, Pasi Kärkkäinen wrote:
> > Hello,
> >
> > Has there been any plans to support running custom post-up scripts for each
> > interface, after "ifup " ?
> >
> > Debian allows you to specify:
> >
Pasi Kärkkäinen píše v Pá 22. 01. 2010 v 11:01 +0200:
> Has there been any plans to support running custom post-up scripts for each
> interface, after "ifup " ?
>
> Debian allows you to specify:
>
> iface eth0 inet static
> ..
> post-up /etc/network/if-up.d/fw.start
>
> I'm looking
On Fri, Jan 22, 2010 at 10:35:13AM +0100, Miloslav Trma?? wrote:
> Pasi Kärkkäinen píše v Pá 22. 01. 2010 v 11:01 +0200:
> > Has there been any plans to support running custom post-up scripts for each
> > interface, after "ifup " ?
> >
> > Debian allows you to specify:
> >
> > iface eth0 inet s
On Fri, Jan 22, 2010 at 01:06:11PM +0200, Pasi Kärkkäinen wrote:
> On Fri, Jan 22, 2010 at 10:35:13AM +0100, Miloslav Trma?? wrote:
> > Pasi Kärkkäinen píše v Pá 22. 01. 2010 v 11:01 +0200:
> > > Has there been any plans to support running custom post-up scripts for
> > > each interface, after "i
Hello,
In Fedora 12 several daemons (e.g. dhclient) were modified to drop
unnecessary capabilities, most importantly the "dac_override"
capability, allowing the daemon to ignore file permission bits. This,
in combination with removing some permissions from important system
directories and files (s
On 01/22/2010 12:19 PM, Miloslav Trmač wrote:
> Hello,
> In Fedora 12 several daemons (e.g. dhclient) were modified to drop
> unnecessary capabilities, most importantly the "dac_override"
> capability, allowing the daemon to ignore file permission bits. This,
> in combination with removing some pe
Hi,
On FC12 I found this:
# ls /usr/bin/.*.hmac
/usr/bin/.fipscheck.hmac
/usr/bin/.ssh.hmac
# rpm -qf /usr/bin/.*.hmac
fipscheck-1.2.0-4.fc12.x86_64
openssh-clients-5.2p1-31.fc12.x86_64
Could somebody provide some insight what these files are (I guess some
checksums) and why they are being ins
On Tue, Jan 19, 2010 at 09:43:49AM +0100, Adrian Reber wrote:
> I would like to update libcdio to the latest version (0.82). This
> requires a rebuild of its dependencies:
>
> audacious-plugins
> gvfs
> kover
> libcddb
> oxine
> pycdio
> qmmp
> xfce4-cddrive-plugin
> xmms2
libcdio and all its dep
On Fri, 2010-01-22 at 12:41 +0100, Ralf Corsepius wrote:
> Hi,
>
> On FC12 I found this:
>
> # ls /usr/bin/.*.hmac
> /usr/bin/.fipscheck.hmac
> /usr/bin/.ssh.hmac
>
> # rpm -qf /usr/bin/.*.hmac
> fipscheck-1.2.0-4.fc12.x86_64
> openssh-clients-5.2p1-31.fc12.x86_64
>
> Could somebody provide so
Ralf Corsepius píše v Pá 22. 01. 2010 v 12:36 +0100:
> On 01/22/2010 12:19 PM, Miloslav Trmač wrote:
> > We can extend the protection to all executables by a simple addition to
> > redhat-rpm-config (https://bugzilla.redhat.com/show_bug.cgi?id=556897 ).
> > After applying this patch, executable fi
On 01/22/2010 01:22 PM, Tomas Mraz wrote:
> On Fri, 2010-01-22 at 12:41 +0100, Ralf Corsepius wrote:
>> Hi,
>>
>> On FC12 I found this:
>>
>> # ls /usr/bin/.*.hmac
>> /usr/bin/.fipscheck.hmac
>> /usr/bin/.ssh.hmac
>>
>> # rpm -qf /usr/bin/.*.hmac
>> fipscheck-1.2.0-4.fc12.x86_64
>> openssh-clients-
Compose started at Fri Jan 22 08:15:08 UTC 2010
Broken deps for i386
--
HippoDraw-python-1.21.1-9.fc12.i586 requires libboost_python.so.5
PyKDE-3.16.6-1.fc13.i686 requires sip-api(6) >= 0:6.0
awn-extras-applets-0.3.2.2
Hello,
I do herewith request to take over the package "mumble", currently owned by
igjurisk.
The maintainer seems to be unresponsive and all previous attempts of contact
have failed.
According to the policy for non-responsive package maintainers, this request
has to be approved
by at least one
On Fri, Jan 22, 2010 at 12:19:49PM +0100, Miloslav Trmač wrote:
> Hello,
> In Fedora 12 several daemons (e.g. dhclient) were modified to drop
> unnecessary capabilities, most importantly the "dac_override"
> capability, allowing the daemon to ignore file permission bits. This,
> in combination wit
Once upon a time, Miloslav TrmaÄ? said:
> We can extend the protection to all executables by a simple addition to
> redhat-rpm-config (https://bugzilla.redhat.com/show_bug.cgi?id=556897 ).
> After applying this patch, executable files in all rebuilt packages
> would not be writeable, most often us
On Fri, Jan 22, 2010 at 01:08:46PM +0200, Pasi Kärkkäinen wrote:
> > > grep ifup-local /etc/sysconfig/network-scripts/ifup-post
> > >
> >
> > Thanks for pointing that out. I was looking at ifup-post,
> > and I thought ifup-local was a script provided by the system,
> > but it seems there's no su
Chris Adams píše v Pá 22. 01. 2010 v 08:06 -0600:
> Once upon a time, Miloslav TrmaÄ? said:
> > We can extend the protection to all executables by a simple addition to
> > redhat-rpm-config (https://bugzilla.redhat.com/show_bug.cgi?id=556897 ).
> > After applying this patch, executable files in a
Once upon a time, Miloslav TrmaÄ? said:
> Chris Adams pÃÅ¡e v Pá 22. 01. 2010 v 08:06 -0600:
> > Once upon a time, Miloslav TrmaÃ? said:
> > > We can extend the protection to all executables by a simple addition to
> > > redhat-rpm-config (https://bugzilla.redhat.com/show_bug.cgi?id=556897 ).
On 01/22/2010 07:53 AM, Ralf Corsepius wrote:
> On 01/22/2010 01:22 PM, Tomas Mraz wrote:
>> These are checksums required by FIPS-140-2 integrity verification checks
>> of the fipscheck and ssh binaries.
>
> I.e. package data.
>
> => These packages are non-FHS compliant and qualify as broken.
I
On Fri, 2010-01-22 at 12:19 +0100, Miloslav Trmač wrote:
> Hello,
> In Fedora 12 several daemons (e.g. dhclient) were modified to drop
> unnecessary capabilities, most importantly the "dac_override"
> capability, allowing the daemon to ignore file permission bits. This,
> in combination with remov
Hello Milos,
Monday, January 18, 2010, 2:27:22 PM, you wrote:
> is there any good way how to handle the situation described at
>
> https://bugzilla.redhat.com/show_bug.cgi?id=528524
>
> ?
>
> I.e. you have a single library (single soname) which can be compiled
> with or without GUI support (with d
On Friday 15 January 2010 15:36:42 Sebastian Dziallas wrote:
>[...]
> I had attempted to package it, since it would be probably of interest
> for the Design Suite, but building currently fails due to [1]. I'm not
> sure whether I'll be able to look into it over the next days, but if
> somebody else
On Fri, 2010-01-22 at 10:24 -0500, Przemek Klosowski wrote:
> I don't believe so---it's not my line of business but I understand that
>
> - in some circumstances (government, regulated companies) encryption
>must be certified to the FIPS 140-2 standard
>
> - on Linux encryption (https, ssh)
On Fri, Jan 22, 2010 at 5:04 PM, Tomas Mraz wrote:
> No, it does not prevent malicious attacker from subverting the
> executable. The integrity check prevents just inadvertent modification
> of the executables/libraries which contain the certified code.
Like prelink? ;-)
m
--
martin.langh...
On 01/22/2010 04:24 PM, Przemek Klosowski wrote:
> On 01/22/2010 07:53 AM, Ralf Corsepius wrote:
>> On 01/22/2010 01:22 PM, Tomas Mraz wrote:
>
>>> These are checksums required by FIPS-140-2 integrity verification checks
>>> of the fipscheck and ssh binaries.
>>
>> I.e. package data.
>>
>> => The
On Fri, Jan 22, 2010 at 4:11 PM, Ralf Corsepius wrote:
> On 01/22/2010 04:24 PM, Przemek Klosowski wrote:
> > On 01/22/2010 07:53 AM, Ralf Corsepius wrote:
> >> On 01/22/2010 01:22 PM, Tomas Mraz wrote:
> >
> >>> These are checksums required by FIPS-140-2 integrity verification
> checks
> >>> of
On Fri, Jan 22, 2010 at 10:11 AM, Ralf Corsepius wrote:
>> - in some circumstances (government, regulated companies) encryption
>> must be certified to the FIPS 140-2 standard
>
> I don't know this "standard".
>
> May-be this "fips standard" collides with the FHS, may-be this standard
> is def
On Fri, 2010-01-22 at 17:08 +0100, Martin Langhoff wrote:
> On Fri, Jan 22, 2010 at 5:04 PM, Tomas Mraz wrote:
> > No, it does not prevent malicious attacker from subverting the
> > executable. The integrity check prevents just inadvertent modification
> > of the executables/libraries which conta
Am Freitag, den 22.01.2010, 14:52 +0100 schrieb Andreas Osowski:
> Hello,
> I do herewith request to take over the package "mumble", currently owned by
> igjurisk.
> The maintainer seems to be unresponsive and all previous attempts of contact
> have failed.
>
> According to the policy for non-re
On 01/22/2010 01:53 PM, Ralf Corsepius wrote:
> On 01/22/2010 01:22 PM, Tomas Mraz wrote:
>> On Fri, 2010-01-22 at 12:41 +0100, Ralf Corsepius wrote:
>>> Hi,
>>>
>>> On FC12 I found this:
>>>
>>> # ls /usr/bin/.*.hmac
>>> /usr/bin/.fipscheck.hmac
>>> /usr/bin/.ssh.hmac
>>>
>>> # rpm -qf /usr/bin/.*
Chris Adams (cmad...@hiwaay.net) said:
> How about moving /usr/bin/runcon to /bin and using that to call bash
> instead?
The problem is that the context it needs to run at isn't static; it
depends on the policy of the machine. Hence, you don't want to hardcode
a runcon call in the script.
Bill
-
Richard Zidlicky (r...@linux-m68k.org) said:
> > .. just wondering why it's under /sbin and not under
> > /etc/sysconfig/network-scripts/
> >
> > It doesn't feel very good to add custom configuration under /sbin.
>
> same opinion here. I have actually used this for a while, adds one more thing
On 01/22/2010 11:34 AM, Denis Leroy wrote:
> Speaking on funny things in /usr/bin
>
> what about '/usr/bin/[', part of cureutils... had never noticed this one
> before.
>
> -denis
I came across that one day, too, and it seemed weird until I thought
about shell scripts:
if [ $foo = "bar" ]
then
On Fri, 22 Jan 2010, Christoph Wickert wrote:
> Am Freitag, den 22.01.2010, 14:52 +0100 schrieb Andreas Osowski:
>> Hello,
>> I do herewith request to take over the package "mumble", currently owned by
>> igjurisk.
>> The maintainer seems to be unresponsive and all previous attempts of contact
> -Original Message-
> From: devel-boun...@lists.fedoraproject.org
> [mailto:devel-boun...@lists.fedoraproject.org] On Behalf Of
> Denis Leroy
> Sent: Friday, January 22, 2010 8:34 AM
> To: Development discussions related to Fedora
> Subject: Re: FC12: Hidden files in /usr/bin/*
>
*sni
Am Freitag, den 22.01.2010, 17:28 +0100 schrieb Christoph Wickert:
> Am Freitag, den 22.01.2010, 14:52 +0100 schrieb Andreas Osowski:
> > Hello,
> > I do herewith request to take over the package "mumble", currently owned by
> > igjurisk.
> > The maintainer seems to be unresponsive and all previou
On 01/22/2010 11:11 AM, Ralf Corsepius wrote:
> On 01/22/2010 04:24 PM, Przemek Klosowski wrote:
>> On 01/22/2010 07:53 AM, Ralf Corsepius wrote:
>>> On 01/22/2010 01:22 PM, Tomas Mraz wrote:
>>
These are checksums required by FIPS-140-2 integrity verification checks
of the fipscheck and
On Fri, Jan 22, 2010 at 11:41 AM, Cleaver, Japheth wrote:
>
> > -Original Message-
> > From: devel-boun...@lists.fedoraproject.org
> > [mailto:devel-boun...@lists.fedoraproject.org] On Behalf Of
> > Denis Leroy
> > Sent: Friday, January 22, 2010 8:34 AM
> > To: Development discussions rela
On Fri, Jan 22, 2010 at 11:23 AM, Garrett Holmstrom
wrote:
> On Fri, Jan 22, 2010 at 10:11 AM, Ralf Corsepius wrote:
>>> - in some circumstances (government, regulated companies) encryption
>>> must be certified to the FIPS 140-2 standard
>>
>> I don't know this "standard".
>>
>> May-be this
I lost my Mac OS X installation a few days ago and hence I need to
orphan isight-firmware-tools:
https://admin.fedoraproject.org/pkgdb/packages/name/isight-firmware-tools
Cheers,
Debarshi
--
One reason that life is complex is that it has a real part and an
imaginary part.
-- Andrew Koenig
--
On Fri, Jan 22, 2010 at 12:10 PM, Jarod Wilson wrote:
> On Fri, Jan 22, 2010 at 11:23 AM, Garrett Holmstrom
> wrote:
>> On Fri, Jan 22, 2010 at 10:11 AM, Ralf Corsepius wrote:
- in some circumstances (government, regulated companies) encryption
must be certified to the FIPS 140-2 s
Once upon a time, Denis Leroy said:
> Speaking on funny things in /usr/bin
>
> what about '/usr/bin/[', part of cureutils... had never noticed this one
> before.
Welcome to the past! :-) IIRC "[" has been in /bin or /usr/bin since
the late 1970s.
--
Chris Adams
Systems and Network Administra
Once upon a time, Bill Nottingham said:
> Jon Ciesla (l...@jcomserv.net) said:
> > My thoughts exactly. What are the less simple fixes that don't change
> > this behaviour?
>
> Essentially, introducing new scripts solely for this purpose that can
> be given a special label and some policy. It'
Once upon a time, Richard Zidlicky said:
> On Fri, Jan 22, 2010 at 01:08:46PM +0200, Pasi Kärkkäinen wrote:
> > It doesn't feel very good to add custom configuration under /sbin.
>
> same opinion here. I have actually used this for a while, adds one more thing
> that needs be verified after syste
https://bugzilla.redhat.com/show_bug.cgi?id=536703
https://bugzilla.redhat.com/attachment.cgi?id=386207&action=diff
https://bugzilla.redhat.com/attachment.cgi?id=386207&action=edit
>From 4d93699a71acb061c5787d2b8b61a0417ce02808 Mon Sep 17 00:00:00 2001
From: Nathan Kinder
Date: Fri, 22 Jan 2010
On 01/21/2010 12:21 PM, Bill Nottingham wrote:
> We have an existing bug where if you're in single-user mode, and
> SELinux is active, various commands don't print to the console. The
> root of this is the single-user shell isn't running in the right
> SELinux context, as there's nothing to distin
On Friday 22 January 2010 10:25:47 am David Malcolm wrote:
> i.e. it seems to me like it's worth going through the Feature process
> (either as a Feature or an Enhancement), if only to capture the standard
> concerns there and create a URL describing the change; see:
> https://fedoraproject.org/wik
On 10-01-21 12:21:45, Bill Nottingham wrote:
> We have an existing bug where if you're in single-user mode, and
> SELinux is active, various commands don't print to the console.
> The root of this is the single-user shell isn't running in the
> right SELinux context, as there's nothing to distingui
On 10-01-22 11:37:51, Bill Nottingham wrote:
> Richard Zidlicky (r...@linux-m68k.org) said:
> > > .. just wondering why it's under /sbin and not under
> > > /etc/sysconfig/network-scripts/
> > >
> > > It doesn't feel very good to add custom configuration under
> > > /sbin.
> >
> > same opinion
On 01/22/2010 09:46 AM, Nathan Kinder wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=536703
https://bugzilla.redhat.com/attachment.cgi?id=386207&action=diff
https://bugzilla.redhat.com/attachment.cgi?id=386207&action=edit
Pushed to master. Thanks to Rich for his review!
Counting objects:
On Fri, Jan 22, 2010 at 01:15:02PM -0500, Steve Grubb wrote:
> On Friday 22 January 2010 10:25:47 am David Malcolm wrote:
> > i.e. it seems to me like it's worth going through the Feature process
> > (either as a Feature or an Enhancement), if only to capture the standard
> > concerns there and cre
On Fri, Jan 22, 2010 at 13:15:04 -0500,
Tony Nelson wrote:
>
> Put SELinux into Permissive mode for single-user mode? Or just print a
> suggestion to do that? (I'd think that SELinux would normally be
> perceived as an obstacle to the normal uses of single-user mode.)
I think doing it auto
On 01/22/2010 11:11 AM, Ralf Corsepius wrote:
>> - in some circumstances (government, regulated companies) encryption
>> must be certified to the FIPS 140-2 standard
>
> I don't know this "standard".
Well, FIPS 140-2 is a requirement put out by US federal government that
every piece of encry
Przemek Klosowski writes:
> On 01/22/2010 11:11 AM, Ralf Corsepius wrote:
>> Does it really mandate pollution /usr/bin and thus $PATH?
> OK, I see, you don't object to the checksums in principle, just to the
> location of the files. I don't believe that FIPS requires a specific
> location for t
Hi,
I'm wondering if anyone tested this upgrade...
[mic...@ozzy ~]$ mc
-bash: /usr/share/mc/bin/mc-wrapper.sh: Nie ma takiego pliku ani katalogu
This is one of my most commonly used program
cut -f1 -d" " .bash_history | sort | uniq -c | sort -nr | head -n 5
612 git
73 sudo
68 exit
On Fri, Jan 22, 2010 at 8:03 PM, Tom Lane wrote:
> The separate /lib directory tree seems the way to go, to me. That way
/usr/share instead of /lib seems more appropriate -
m
--
martin.langh...@gmail.com
mar...@laptop.org -- School Server Architect
- ask interesting questions
- don't get
Martin Langhoff writes:
> On Fri, Jan 22, 2010 at 8:03 PM, Tom Lane wrote:
>> The separate /lib directory tree seems the way to go, to me. That way
> /usr/share instead of /lib seems more appropriate -
Hardly. Checksums on executables are going to be platform-specific.
Putting them under /sha
On Friday 22 January 2010 01:30:11 pm Richard Zidlicky wrote:
> > We would want to change the owner write permission bit for all
> > executables. In F-12 we took care of the major directories, this is
> > phase 2 of the same project where we take a bigger step. Phase 1 was
> > proving that the mis
On 01/22/2010 02:03 PM, Tom Lane wrote:
> Przemek Klosowski writes:
>> On 01/22/2010 11:11 AM, Ralf Corsepius wrote:
>>> Does it really mandate pollution /usr/bin and thus $PATH?
>
>> OK, I see, you don't object to the checksums in principle, just to the
>> location of the files. I don't believe
On Fri, Jan 22, 2010 at 01:13:06PM -0500, Tony Nelson wrote:
>
> Perhaps there should be a default /sbin/ifup-local script that
> dispatches to /etc/sysconfig/network-scripts/ifup-local/?
> It could contain useful comments, including that it is by default
> replaceable as its target directory
Tony Nelson (tonynel...@georgeanelson.com) said:
> > > same opinion here. I have actually used this for a while, adds
> > > one more thing that needs be verified after system upgrades, not
> > > very nice.
> >
> > Realistically, the conglomeration of configuration and scripts in
> > /etc/syscon
On Fri, Jan 22, 2010 at 03:42:47PM -0500, Bill Nottingham wrote:
> Tony Nelson (tonynel...@georgeanelson.com) said:
> > > > same opinion here. I have actually used this for a while, adds
> > > > one more thing that needs be verified after system upgrades, not
> > > > very nice.
> > >
> > > Real
On 10-01-22 13:29:11, Bruno Wolff III wrote:
> On Fri, Jan 22, 2010 at 13:15:04 -0500,
> Tony Nelson wrote:
> >
> > Put SELinux into Permissive mode for single-user mode? Or just
> > print a suggestion to do that? (I'd think that SELinux would
> > normally be perceived as an obstacle to the
Martin Langhoff wrote:
> /usr/share instead of /lib seems more appropriate -
/usr/share is for architecture-independent files. These checksums are as
architecture-specific as the executables they pertain to. But they should be in
/usr/lib*/, not in /lib.
Björn Persson
signature.asc
Descriptio
On Fri, Jan 22, 2010 at 10:05:04PM +0100, Richard Zidlicky wrote:
> On Fri, Jan 22, 2010 at 03:42:47PM -0500, Bill Nottingham wrote:
> > Tony Nelson (tonynel...@georgeanelson.com) said:
> > > > > same opinion here. I have actually used this for a while, adds
> > > > > one more thing that needs be
On Fri, Jan 22, 2010 at 03:06:24PM -0500, Peter Jones wrote:
> Well, the standard IIRC does want them to be separate, though again it's
> important to realize that this check isn't meant to protect against an
> attack, but rather to check against erroneous corruption of the binary. It
> seems unlik
On 01/22/2010 05:30 PM, Matt Domsch wrote:
> On Fri, Jan 22, 2010 at 03:06:24PM -0500, Peter Jones wrote:
>> Well, the standard IIRC does want them to be separate, though again it's
>> important to realize that this check isn't meant to protect against an
>> attack, but rather to check against erro
We also +R'd #fedora-admin so the recent freenode spammers aren't as
annoying. This means you have to be registered to chat with us. we'll
revert in the future.
-Mike
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
I'm building a package for levmar. Upstream does not use autoconf,
automake, or libtool. The supplied makefile builds a statically linked
library, liblevmar.a. With trivial changes I can build a shared library
liblevmar.so instead, and I've verified that this works with the
supplied demo pro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/22/2010 05:22 PM, Eric Smith wrote:
> Can I just do the shared library versioning
> "by hand", by creating the appropriate symlinks in the package? Or is
> there some other preferred way to deal with this kind of situation?
The link line has
2010/1/22 Miloslav Trmač :
> Hello,
> In Fedora 12 several daemons (e.g. dhclient) were modified to drop
> unnecessary capabilities, most importantly the "dac_override"
> capability, allowing the daemon to ignore file permission bits. This,
> in combination with removing some permissions from impo
Once upon a time, Eric Smith said:
> I don't want to replace the upstream Makefile with use of autoconf and
> automake, and the libtool documentation doesn't really explain how to
> use libtool without those. Can I just do the shared library versioning
> "by hand", by creating the appropriate
76 matches
Mail list logo
