On Tue, 2010-02-02 at 22:56 +0100, Björn Persson wrote:
> Tomas Mraz wrote:
> > The library will work fine and it will not compute the checksum at all
> > if the FIPS mode is not enabled which is the normal situation.
>
> Then perhaps FIPS mode can be left disabled until /usr has been mounted, so
On Tue, 2010-02-02 at 21:54 +0100, Till Maas wrote:
> On Tue, Feb 02, 2010 at 09:30:44PM +0100, Tomas Mraz wrote:
> > On Tue, 2010-02-02 at 20:13 +0100, Till Maas wrote:
> > > On Tue, Feb 02, 2010 at 10:28:11AM +0100, Tomas Mraz wrote:
> > >
> > > > I am sorry, but I do not see a real need for s
Tomas Mraz wrote:
> The library will work fine and it will not compute the checksum at all
> if the FIPS mode is not enabled which is the normal situation.
Then perhaps FIPS mode can be left disabled until /usr has been mounted, so
that the checksum can be in %{_libdir}/fipscheck?
Björn Persson
On Tue, Feb 02, 2010 at 09:30:44PM +0100, Tomas Mraz wrote:
> On Tue, 2010-02-02 at 20:13 +0100, Till Maas wrote:
> > On Tue, Feb 02, 2010 at 10:28:11AM +0100, Tomas Mraz wrote:
> >
> > > I am sorry, but I do not see a real need for special guideline for the
> > > fipscheck checksums. The policy
On Tue, 2010-02-02 at 20:13 +0100, Till Maas wrote:
> On Tue, Feb 02, 2010 at 10:28:11AM +0100, Tomas Mraz wrote:
>
> > I am sorry, but I do not see a real need for special guideline for the
> > fipscheck checksums. The policy where these checksums should/will be
> > placed should be decided by t
On Tue, 2010-02-02 at 21:04 +0100, Björn Persson wrote:
> Tomas Mraz wrote:
> > There is still a slight problem with the library checksums especially
> > for the libgcrypt library which currently resides in /%{_lib}. This
> > means that if it looks for the checksum in %{_libdir}/fipscheck the /usr
Tomas Mraz wrote:
> There is still a slight problem with the library checksums especially
> for the libgcrypt library which currently resides in /%{_lib}. This
> means that if it looks for the checksum in %{_libdir}/fipscheck the /usr
> might not be mounted during the checksum verification.
Will a
On Tue, Feb 02, 2010 at 10:28:11AM +0100, Tomas Mraz wrote:
> I am sorry, but I do not see a real need for special guideline for the
> fipscheck checksums. The policy where these checksums should/will be
> placed should be decided by the fipscheck package itself. Of course I
As soon as multiple p
On Mon, 2010-02-01 at 14:00 -0500, Toshio Kuratomi wrote:
> On Mon, Feb 01, 2010 at 01:38:13PM -0500, Toshio Kuratomi wrote:
> >
> > 1) The present packages need to be fixecd. Sounds like fipscheck, hmaccalc,
> > and openssh. They are violating the FHS which is prohibited by the
> > Guidelines.
On Mon, Feb 01, 2010 at 01:38:13PM -0500, Toshio Kuratomi wrote:
>
> 1) The present packages need to be fixecd. Sounds like fipscheck, hmaccalc,
> and openssh. They are violating the FHS which is prohibited by the
> Guidelines. Ralf, have you opened bugs?
>
> 2) We need to decide where to plac
On Mon, 1 Feb 2010 13:38:13 -0500
Toshio Kuratomi wrote:
> On Fri, Jan 22, 2010 at 12:13:06PM -0500, Jarod Wilson wrote:
> > On Fri, Jan 22, 2010 at 12:10 PM, Jarod Wilson
> > wrote:
> > >> I have no idea if it actually requires them to be alongside the
> > >> executables, but hopefully the link
On Fri, Jan 22, 2010 at 12:13:06PM -0500, Jarod Wilson wrote:
> On Fri, Jan 22, 2010 at 12:10 PM, Jarod Wilson wrote:
> >> I have no idea if it actually requires them to be alongside the
> >> executables, but hopefully the link will help.
> >
> > It doesn't. Also, ugh. I'm the one who actually rev
"Bryn M. Reeves" writes:
> On Mon, 2010-01-25 at 17:44 +0100, Andreas Schwab wrote:
>> "Bryn M. Reeves" writes:
>>
>> > [ may be a built in but then again (as its presence
>> > in /usr/bin implies) it may not be :).
>>
>> Like any other command.
>
> But unlike '[[' which is the point I was re
On Mon, 2010-01-25 at 17:44 +0100, Andreas Schwab wrote:
> "Bryn M. Reeves" writes:
>
> > [ may be a built in but then again (as its presence
> > in /usr/bin implies) it may not be :).
>
> Like any other command.
But unlike '[[' which is the point I was replying to. Afaik you can't
provide a '
"Bryn M. Reeves" writes:
> [ may be a built in but then again (as its presence
> in /usr/bin implies) it may not be :).
Like any other command.
Andreas.
--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something comple
On Mon, 2010-01-25 at 16:44 +0100, Andreas Schwab wrote:
> Garrett Holmstrom writes:
>
> > On Mon, Jan 25, 2010 at 6:09 AM, Bryn M. Reeves wrote:
> >> It's cute isn't it? I had the biggest grin the day I realised that '['
> >> was just another command..
> >
> > That's the reason [[ can use speci
Garrett Holmstrom writes:
> On Mon, Jan 25, 2010 at 6:09 AM, Bryn M. Reeves wrote:
>> It's cute isn't it? I had the biggest grin the day I realised that '['
>> was just another command..
>
> That's the reason [[ can use special characters like < and > without
> escaping, while [ can't: [[ is a
On Mon, Jan 25, 2010 at 6:09 AM, Bryn M. Reeves wrote:
> It's cute isn't it? I had the biggest grin the day I realised that '['
> was just another command..
That's the reason [[ can use special characters like < and > without
escaping, while [ can't: [[ is a builtin, but [ isn't.
--
Garrett Hol
On Fri, 2010-01-22 at 08:41 -0800, Cleaver, Japheth wrote:
> > Denis Leroy
> > what about '/usr/bin/[', part of cureutils... had never
> > noticed this one before.
> >
> > -denis
>
>
> Isn't that simply what makes "if [ (blah) ]" work?
It's cute isn't it? I had the biggest grin the day I reali
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
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
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 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
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 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
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
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
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
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
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
M
> > To: Development discussions related to Fedora
> > Subject: Re: FC12: Hidden files in /usr/bin/*
>
> *snip*
>
> > Speaking on funny things in /usr/bin
> >
> > what about '/usr/bin/[', part of cureutils... had never
> > noticed this one before.
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
> -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: Hid
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 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/.*
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
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, 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 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 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 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 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 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-
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
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
45 matches
Mail list logo
