[users] yum seg fault on repoforge extras

[RobertH]

Dag

do you know why yum on centos4 is segfaulting on repoforge "extra" in the
past week or two?

please forgive my lack of knowledge on it, i just see the result

if you can direct me, ill be happy to gather more info

i just noticed someone on centos list posted same

- rh

[Grant McChesney]

Post by RobertH
Dag
do you know why yum on centos4 is segfaulting on repoforge "extra" in the
past week or two?
please forgive my lack of knowledge on it, i just see the result
if you can direct me, ill be happy to gather more info
i just noticed someone on centos list posted same
- rh

I'm getting a segfault when I yum update with rpmforge enabled as well on
CentOS 5.6.

Grant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20110726/92c4f483/attachment.html

[Dag Wieers]

Post by Grant McChesney

Post by RobertH
do you know why yum on centos4 is segfaulting on repoforge "extra" in the
past week or two?
please forgive my lack of knowledge on it, i just see the result
if you can direct me, ill be happy to gather more info
i just noticed someone on centos list posted same

I'm getting a segfault when I yum update with rpmforge enabled as well on
CentOS 5.6.

Whatever the cause, yum segfaulting on any repository metadata is a
security problem, possibly exploitable. We are looking at our side to find
the cause (or a workaround). I do not seem to be able to reproduce this as
of yet.

Regardless someone should fill this as a potential security-problem with
the yum maintainers. I think they should be very concerned :-/

[Yury V. Zaytsev]

Post by Dag Wieers
Regardless someone should fill this as a potential security-problem with
the yum maintainers. I think they should be very concerned :-/

Maybe a good idea to keep a backup of the metadata that is causing this
issue? Otherwise I don't see how one would be able to reproduce it if
later on we manage to find a workaround for that.

[Dag Wieers]

Post by Yury V. Zaytsev

Post by Dag Wieers
Regardless someone should fill this as a potential security-problem with
the yum maintainers. I think they should be very concerned :-/

Maybe a good idea to keep a backup of the metadata that is causing this
issue? Otherwise I don't see how one would be able to reproduce it if
later on we manage to find a workaround for that.

I always keep a copy of the past 15 days of metadata (and repository)
because it could help us to revert to an older set when necessary. I also
keep 2 copies of each previous month as well in an archive...

[Thomas Harold]

Post by Dag Wieers

Post by Yury V. Zaytsev

Post by Dag Wieers
Regardless someone should fill this as a potential security-problem with
the yum maintainers. I think they should be very concerned :-/

Maybe a good idea to keep a backup of the metadata that is causing this
issue? Otherwise I don't see how one would be able to reproduce it if
later on we manage to find a workaround for that.

I always keep a copy of the past 15 days of metadata (and repository)
because it could help us to revert to an older set when necessary. I also
keep 2 copies of each previous month as well in an archive...

On a system exhibiting this issue, which files should we look at?

# yum info rpmforge-release
Loaded plugins: rhnplugin, security
rpmforge: [#### ] 471/10722Segmentation fault

I've deleted everything under /var/cache/yum/ and then redid the yum
command. It dies on either the rpmforge or the rpmforge-extras line.

Contents of /var/cache/yum/rpmforge after the yum command fails.

# ls -lt
total 9856

-rw-r--r-- 1 root root 20480 Jul 26 11:25 primary.xml.gz.sqlite
-rw-r--r-- 1 root root 17024 Jul 26 11:25 primary.xml.gz.sqlite-journal

-rw-r--r-- 1 root root 0 Jul 26 11:17 cachecookie
-rw-r--r-- 1 root root 174 Jul 26 11:17 mirrorlist.txt
drwxr-xr-x 2 root root 4096 Jul 26 11:17 packages
-rw-r--r-- 1 root root 1095 Jul 25 21:58 repomd.xml
-rw-r--r-- 1 root root 4659198 Jul 25 21:58 filelists.xml.gz
-rw-r--r-- 1 root root 1273348 Jul 25 21:58 other.xml.gz
-rw-r--r-- 1 root root 4044478 Jul 25 21:58 primary.xml.gz

[Joe Pruett]

i have done some strace'ing and it is dieing while reading
/var/cache/yum/rpmforge/primary.xml.gz. i have externally tested that
file and can gunzip it just fine and xmllint doesn't find any issues
either, so it would appear to be the data itself. i'll do a bit more
poking to see if i can track down anything further.

Post by Dag Wieers

Post by Yury V. Zaytsev

Post by Dag Wieers
Regardless someone should fill this as a potential security-problem with
the yum maintainers. I think they should be very concerned :-/

Maybe a good idea to keep a backup of the metadata that is causing this
issue? Otherwise I don't see how one would be able to reproduce it if
later on we manage to find a workaround for that.

I always keep a copy of the past 15 days of metadata (and repository)
because it could help us to revert to an older set when necessary. I also
keep 2 copies of each previous month as well in an archive...

[Orion Poplawski]

Post by Joe Pruett
i have done some strace'ing and it is dieing while reading
/var/cache/yum/rpmforge/primary.xml.gz. i have externally tested that
file and can gunzip it just fine and xmllint doesn't find any issues
either, so it would appear to be the data itself. i'll do a bit more
poking to see if i can track down anything further.

I've been updating the bug. Looks like the pkgId for mhash is null. strlen
gets called on the null pointer. Still need to look deeper.

[Orion Poplawski]

Post by Orion Poplawski

Post by Joe Pruett
i have done some strace'ing and it is dieing while reading
/var/cache/yum/rpmforge/primary.xml.gz. i have externally tested that
file and can gunzip it just fine and xmllint doesn't find any issues
either, so it would appear to be the data itself. i'll do a bit more
poking to see if i can track down anything further.

I've been updating the bug. Looks like the pkgId for mhash is null. strlen
gets called on the null pointer. Still need to look deeper.

So, yes there is a bug in yum, but it is triggered by a bad primary.xml file:

<package type="rpm"><name>mhash-devel</name><arch>x86_64</arch><version
epoch="0" ver="0.9.9" rel="1.el5.rf"/><checksum type="sha"
pkgid="YES"></checksum><summary>Header files and libraries for developing apps
which will use mhash</summary>

The above is missing the checksum. compare to:

<package type="rpm"><name>mhash</name><arch>x86_64</arch><version epoch="0"
ver="0.9.9" rel="1.el5.rf"/><checksum type="sha"
pkgid="YES">6d99a4ae71018caea53b2ee45c4feedf6d12a4f0</checksum><summary>Thread-safe
hash library</summary>

[Joe Pruett]

ah, that makes more sense. i was seeing the strlen(null) call and
line=1785 in the stack but hadn't gotten further. sounds like you're
closer to finding the issue, so i'll let you finish.

Post by Orion Poplawski

Post by Joe Pruett
i have done some strace'ing and it is dieing while reading
/var/cache/yum/rpmforge/primary.xml.gz. i have externally tested that
file and can gunzip it just fine and xmllint doesn't find any issues
either, so it would appear to be the data itself. i'll do a bit more
poking to see if i can track down anything further.

I've been updating the bug. Looks like the pkgId for mhash is null. strlen
gets called on the null pointer. Still need to look deeper.

[Joe Pruett]

i see 7 packages with empty checksum clauses. sounds like something
went wrong with the repo data creator?

Post by Joe Pruett
ah, that makes more sense. i was seeing the strlen(null) call and
line=1785 in the stack but hadn't gotten further. sounds like you're
closer to finding the issue, so i'll let you finish.

Post by Orion Poplawski

Post by Joe Pruett
i have done some strace'ing and it is dieing while reading
/var/cache/yum/rpmforge/primary.xml.gz. i have externally tested that
file and can gunzip it just fine and xmllint doesn't find any issues
either, so it would appear to be the data itself. i'll do a bit more
poking to see if i can track down anything further.

I've been updating the bug. Looks like the pkgId for mhash is null. strlen
gets called on the null pointer. Still need to look deeper.

[Yury V. Zaytsev]

Post by Joe Pruett
i see 7 packages with empty checksum clauses. sounds like something
went wrong with the repo data creator?

Yep, in fact there are several issues as far as I can understand:

1) createrepo creating invalid repodata
2) yum-metadata-parser segfaulting on this metadata

They are being taken care of right now...

[Yury V. Zaytsev]

Post by Joe Pruett
i see 7 packages with empty checksum clauses. sounds like something
went wrong with the repo data creator?

Yep, in fact there are several issues as far as I can understand:

1) createrepo creating invalid repodata
2) yum-metadata-parser segfaulting on this metadata

They are being taken care of right now...

[Joe Pruett]

i see 7 packages with empty checksum clauses. sounds like something
went wrong with the repo data creator?

Post by Joe Pruett
ah, that makes more sense. i was seeing the strlen(null) call and
line=1785 in the stack but hadn't gotten further. sounds like you're
closer to finding the issue, so i'll let you finish.

Post by Orion Poplawski

Post by Joe Pruett
i have done some strace'ing and it is dieing while reading
/var/cache/yum/rpmforge/primary.xml.gz. i have externally tested that
file and can gunzip it just fine and xmllint doesn't find any issues
either, so it would appear to be the data itself. i'll do a bit more
poking to see if i can track down anything further.

I've been updating the bug. Looks like the pkgId for mhash is null. strlen
gets called on the null pointer. Still need to look deeper.

[Orion Poplawski]

Post by Orion Poplawski

Post by Joe Pruett
i have done some strace'ing and it is dieing while reading
/var/cache/yum/rpmforge/primary.xml.gz. i have externally tested that
file and can gunzip it just fine and xmllint doesn't find any issues
either, so it would appear to be the data itself. i'll do a bit more
poking to see if i can track down anything further.

I've been updating the bug. Looks like the pkgId for mhash is null. strlen
gets called on the null pointer. Still need to look deeper.

So, yes there is a bug in yum, but it is triggered by a bad primary.xml file:

<package type="rpm"><name>mhash-devel</name><arch>x86_64</arch><version
epoch="0" ver="0.9.9" rel="1.el5.rf"/><checksum type="sha"
pkgid="YES"></checksum><summary>Header files and libraries for developing apps
which will use mhash</summary>

The above is missing the checksum. compare to:

<package type="rpm"><name>mhash</name><arch>x86_64</arch><version epoch="0"
ver="0.9.9" rel="1.el5.rf"/><checksum type="sha"
pkgid="YES">6d99a4ae71018caea53b2ee45c4feedf6d12a4f0</checksum><summary>Thread-safe
hash library</summary>

[Joe Pruett]

ah, that makes more sense. i was seeing the strlen(null) call and
line=1785 in the stack but hadn't gotten further. sounds like you're
closer to finding the issue, so i'll let you finish.

Post by Orion Poplawski

Post by Joe Pruett
i have done some strace'ing and it is dieing while reading
/var/cache/yum/rpmforge/primary.xml.gz. i have externally tested that
file and can gunzip it just fine and xmllint doesn't find any issues
either, so it would appear to be the data itself. i'll do a bit more
poking to see if i can track down anything further.

I've been updating the bug. Looks like the pkgId for mhash is null. strlen
gets called on the null pointer. Still need to look deeper.

[Joe Pruett]

i am loading debuginfo packages and some stack trace clues are pointing
to mhash-devel missing checksum data. the xml has:
<checksum type="sha" pkgid="YES"></checksum>

could that be the issue?

Post by Joe Pruett
i have done some strace'ing and it is dieing while reading
/var/cache/yum/rpmforge/primary.xml.gz. i have externally tested that
file and can gunzip it just fine and xmllint doesn't find any issues
either, so it would appear to be the data itself. i'll do a bit more
poking to see if i can track down anything further.

Post by Dag Wieers

Post by Yury V. Zaytsev

Post by Dag Wieers
Regardless someone should fill this as a potential security-problem with
the yum maintainers. I think they should be very concerned :-/

Maybe a good idea to keep a backup of the metadata that is causing this
issue? Otherwise I don't see how one would be able to reproduce it if
later on we manage to find a workaround for that.

I always keep a copy of the past 15 days of metadata (and repository)
because it could help us to revert to an older set when necessary. I also
keep 2 copies of each previous month as well in an archive...

_______________________________________________
users mailing list
users at lists.repoforge.org
http://lists.repoforge.org/mailman/listinfo/users

[Dag Wieers]

Post by Joe Pruett

Post by Joe Pruett
i have done some strace'ing and it is dieing while reading
/var/cache/yum/rpmforge/primary.xml.gz. i have externally tested that
file and can gunzip it just fine and xmllint doesn't find any issues
either, so it would appear to be the data itself. i'll do a bit more
poking to see if i can track down anything further.

i am loading debuginfo packages and some stack trace clues are pointing
<checksum type="sha" pkgid="YES"></checksum>
could that be the issue?

On #yum apparently the issue is caused by one (or more) bugs in
createrepo when using --update. This is indeed something we introduced in
may when we migrated the server from CentOS-4 to RHEL5 and the new
createrepo did have the --update option.

Unfortunately this exploit is part of RHEL5, both createrepo and
yum-metadata-parser.

Now, the yum-developers don't consider this a bug, because it cannot be
exploited if the repository metadata is signed. (That is, if the exploiter
is not able to sign the metadata)

I don't agree with this, yum segfaulting is something that should be
fixed, regardless of how people are using it. Anyone interested to report
this to get a CVE ? ;-)

[R P Herrold]

Post by Dag Wieers
I don't agree with this, yum segfaulting is something that should be
fixed, regardless of how people are using it. Anyone interested to report
this to get a CVE ? ;-)

1. build an exploit reproducer

2. file a bug showing the potential, valid configuration is
exploitable in the Red hat tracker, setting the security
matter flag on

3. cc me in on the bug ... you watch my RH tracker bug
activities presently as I recall, and so have the account
details, and I'll upstream the request to MITRE if Red Hat
does not

best regards,

-- Russ herrold

[R P Herrold]

Post by Dag Wieers
I don't agree with this, yum segfaulting is something that should be
fixed, regardless of how people are using it. Anyone interested to report
this to get a CVE ? ;-)

1. build an exploit reproducer

2. file a bug showing the potential, valid configuration is
exploitable in the Red hat tracker, setting the security
matter flag on

3. cc me in on the bug ... you watch my RH tracker bug
activities presently as I recall, and so have the account
details, and I'll upstream the request to MITRE if Red Hat
does not

best regards,

-- Russ herrold

[Dag Wieers]

Post by Joe Pruett

Post by Joe Pruett
i have done some strace'ing and it is dieing while reading
/var/cache/yum/rpmforge/primary.xml.gz. i have externally tested that
file and can gunzip it just fine and xmllint doesn't find any issues
either, so it would appear to be the data itself. i'll do a bit more
poking to see if i can track down anything further.

i am loading debuginfo packages and some stack trace clues are pointing
<checksum type="sha" pkgid="YES"></checksum>
could that be the issue?

On #yum apparently the issue is caused by one (or more) bugs in
createrepo when using --update. This is indeed something we introduced in
may when we migrated the server from CentOS-4 to RHEL5 and the new
createrepo did have the --update option.

Unfortunately this exploit is part of RHEL5, both createrepo and
yum-metadata-parser.

Now, the yum-developers don't consider this a bug, because it cannot be
exploited if the repository metadata is signed. (That is, if the exploiter
is not able to sign the metadata)

I don't agree with this, yum segfaulting is something that should be
fixed, regardless of how people are using it. Anyone interested to report
this to get a CVE ? ;-)

[Orion Poplawski]

Post by Joe Pruett
i have done some strace'ing and it is dieing while reading
/var/cache/yum/rpmforge/primary.xml.gz. i have externally tested that
file and can gunzip it just fine and xmllint doesn't find any issues
either, so it would appear to be the data itself. i'll do a bit more
poking to see if i can track down anything further.

I've been updating the bug. Looks like the pkgId for mhash is null. strlen
gets called on the null pointer. Still need to look deeper.

[Joe Pruett]

i am loading debuginfo packages and some stack trace clues are pointing
to mhash-devel missing checksum data. the xml has:
<checksum type="sha" pkgid="YES"></checksum>

could that be the issue?

Post by Joe Pruett
i have done some strace'ing and it is dieing while reading
/var/cache/yum/rpmforge/primary.xml.gz. i have externally tested that
file and can gunzip it just fine and xmllint doesn't find any issues
either, so it would appear to be the data itself. i'll do a bit more
poking to see if i can track down anything further.

Post by Dag Wieers

Post by Yury V. Zaytsev

Post by Dag Wieers
Regardless someone should fill this as a potential security-problem with
the yum maintainers. I think they should be very concerned :-/

Maybe a good idea to keep a backup of the metadata that is causing this
issue? Otherwise I don't see how one would be able to reproduce it if
later on we manage to find a workaround for that.

I always keep a copy of the past 15 days of metadata (and repository)
because it could help us to revert to an older set when necessary. I also
keep 2 copies of each previous month as well in an archive...

_______________________________________________
users mailing list
users at lists.repoforge.org
http://lists.repoforge.org/mailman/listinfo/users

[Thomas Harold]

Post by Dag Wieers

Post by Yury V. Zaytsev

Post by Dag Wieers
Regardless someone should fill this as a potential security-problem with
the yum maintainers. I think they should be very concerned :-/

Maybe a good idea to keep a backup of the metadata that is causing this
issue? Otherwise I don't see how one would be able to reproduce it if
later on we manage to find a workaround for that.

I always keep a copy of the past 15 days of metadata (and repository)
because it could help us to revert to an older set when necessary. I also
keep 2 copies of each previous month as well in an archive...

On a system exhibiting this issue, which files should we look at?

# yum info rpmforge-release
Loaded plugins: rhnplugin, security
rpmforge: [#### ] 471/10722Segmentation fault

I've deleted everything under /var/cache/yum/ and then redid the yum
command. It dies on either the rpmforge or the rpmforge-extras line.

Contents of /var/cache/yum/rpmforge after the yum command fails.

# ls -lt
total 9856

-rw-r--r-- 1 root root 20480 Jul 26 11:25 primary.xml.gz.sqlite
-rw-r--r-- 1 root root 17024 Jul 26 11:25 primary.xml.gz.sqlite-journal

-rw-r--r-- 1 root root 0 Jul 26 11:17 cachecookie
-rw-r--r-- 1 root root 174 Jul 26 11:17 mirrorlist.txt
drwxr-xr-x 2 root root 4096 Jul 26 11:17 packages
-rw-r--r-- 1 root root 1095 Jul 25 21:58 repomd.xml
-rw-r--r-- 1 root root 4659198 Jul 25 21:58 filelists.xml.gz
-rw-r--r-- 1 root root 1273348 Jul 25 21:58 other.xml.gz
-rw-r--r-- 1 root root 4044478 Jul 25 21:58 primary.xml.gz

[Joe Pruett]

i have done some strace'ing and it is dieing while reading
/var/cache/yum/rpmforge/primary.xml.gz. i have externally tested that
file and can gunzip it just fine and xmllint doesn't find any issues
either, so it would appear to be the data itself. i'll do a bit more
poking to see if i can track down anything further.

Post by Dag Wieers

Post by Yury V. Zaytsev

Post by Dag Wieers
Regardless someone should fill this as a potential security-problem with
the yum maintainers. I think they should be very concerned :-/

Maybe a good idea to keep a backup of the metadata that is causing this
issue? Otherwise I don't see how one would be able to reproduce it if
later on we manage to find a workaround for that.

I always keep a copy of the past 15 days of metadata (and repository)
because it could help us to revert to an older set when necessary. I also
keep 2 copies of each previous month as well in an archive...

[Dag Wieers]

Post by Yury V. Zaytsev

Post by Dag Wieers
Regardless someone should fill this as a potential security-problem with
the yum maintainers. I think they should be very concerned :-/

Maybe a good idea to keep a backup of the metadata that is causing this
issue? Otherwise I don't see how one would be able to reproduce it if
later on we manage to find a workaround for that.

I always keep a copy of the past 15 days of metadata (and repository)
because it could help us to revert to an older set when necessary. I also
keep 2 copies of each previous month as well in an archive...

[Orion Poplawski]

Post by Dag Wieers
Regardless someone should fill this as a potential security-problem with
the yum maintainers. I think they should be very concerned :-/

I filed https://bugzilla.redhat.com/show_bug.cgi?id=725798 against RHEL5.6

[Yury V. Zaytsev]

Post by Dag Wieers
Regardless someone should fill this as a potential security-problem with
the yum maintainers. I think they should be very concerned :-/

Maybe a good idea to keep a backup of the metadata that is causing this
issue? Otherwise I don't see how one would be able to reproduce it if
later on we manage to find a workaround for that.

[Orion Poplawski]

Post by Dag Wieers
Regardless someone should fill this as a potential security-problem with
the yum maintainers. I think they should be very concerned :-/

I filed https://bugzilla.redhat.com/show_bug.cgi?id=725798 against RHEL5.6

[Ben]

Post by Grant McChesney

Post by RobertH
Dag
do you know why yum on centos4 is segfaulting on repoforge "extra" in the
past week or two?
please forgive my lack of knowledge on it, i just see the result
if you can direct me, ill be happy to gather more info
i just noticed someone on centos list posted same
- rh

I'm getting a segfault when I yum update with rpmforge enabled as well on
CentOS 5.6.
Grant

Likewise on RHEL 5.6 (multiple instances).

Ben

[Dag Wieers]

Post by Grant McChesney

Post by RobertH
do you know why yum on centos4 is segfaulting on repoforge "extra" in the
past week or two?
please forgive my lack of knowledge on it, i just see the result
if you can direct me, ill be happy to gather more info
i just noticed someone on centos list posted same

I'm getting a segfault when I yum update with rpmforge enabled as well on
CentOS 5.6.

Whatever the cause, yum segfaulting on any repository metadata is a
security problem, possibly exploitable. We are looking at our side to find
the cause (or a workaround). I do not seem to be able to reproduce this as
of yet.

Regardless someone should fill this as a potential security-problem with
the yum maintainers. I think they should be very concerned :-/

[Ben]

Post by Grant McChesney

Post by RobertH
Dag
do you know why yum on centos4 is segfaulting on repoforge "extra" in the
past week or two?
please forgive my lack of knowledge on it, i just see the result
if you can direct me, ill be happy to gather more info
i just noticed someone on centos list posted same
- rh

I'm getting a segfault when I yum update with rpmforge enabled as well on
CentOS 5.6.
Grant

Likewise on RHEL 5.6 (multiple instances).

Ben

[Fred Kienker]

-----Original Message-----
From: RobertH [mailto:roberth at abbacomm.net]
Sent: Tuesday, July 26, 2011 10:30 AM
To: users at lists.repoforge.org
Subject: [users] yum seg fault on repoforge extras
Dag
do you know why yum on centos4 is segfaulting on repoforge
"extra" in the past week or two?
please forgive my lack of knowledge on it, i just see the result
if you can direct me, ill be happy to gather more info
i just noticed someone on centos list posted same
- rh
_______________________________________________
users mailing list
users at lists.repoforge.org
http://lists.repoforge.org/mailman/listinfo/users

I have *exactly* the same problem. Currently only happening on one out
of 26 servers.

Best regards,

Fred

Fred Kienker

AT4B
"Advanced Technologies for Business"

This transmission may contain information that is privileged,
confidential and/or exempt from disclosure under applicable law. If you
are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution, or use of the information contained
herein (including any reliance thereon) is STRICTLY PROHIBITED. If you
received this transmission in error, please immediately contact the
sender and destroy the material in its entirety, whether in electronic
or hard copy format. Thank you.

[Fred Kienker]

-----Original Message-----
From: Dag Wieers [mailto:dag at wieers.com]
Sent: Tuesday, July 26, 2011 11:00 AM
To: Discussions regarding Repoforge for users
Subject: Re: [users] yum seg fault on repoforge extras

On Tue, Jul 26, 2011 at 8:30 AM, RobertH

Post by RobertH
do you know why yum on centos4 is segfaulting on repoforge

"extra" in

Post by RobertH
the past week or two?
please forgive my lack of knowledge on it, i just see the result
if you can direct me, ill be happy to gather more info
i just noticed someone on centos list posted same

I'm getting a segfault when I yum update with rpmforge

enabled as well

on CentOS 5.6.

Whatever the cause, yum segfaulting on any repository
metadata is a security problem, possibly exploitable. We are
looking at our side to find the cause (or a workaround). I do
not seem to be able to reproduce this as of yet.
Regardless someone should fill this as a potential
security-problem with the yum maintainers. I think they
should be very concerned :-/
--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/
[Any errors in spelling, tact or fact are transmission
errors] _______________________________________________
users mailing list
users at lists.repoforge.org
http://lists.repoforge.org/mailman/listinfo/users

Originally it was only one server. It appears the problem is spreading
to the rest of the servers.

Best regards,

Fred

Fred Kienker

AT4B
"Advanced Technologies for Business"

This transmission may contain information that is privileged,
confidential and/or exempt from disclosure under applicable law. If you
are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution, or use of the information contained
herein (including any reliance thereon) is STRICTLY PROHIBITED. If you
received this transmission in error, please immediately contact the
sender and destroy the material in its entirety, whether in electronic
or hard copy format. Thank you.

[RobertH]

Dag

do you know why yum on centos4 is segfaulting on repoforge "extra" in the
past week or two?

please forgive my lack of knowledge on it, i just see the result

if you can direct me, ill be happy to gather more info

i just noticed someone on centos list posted same

- rh

[Grant McChesney]

Post by RobertH
Dag
do you know why yum on centos4 is segfaulting on repoforge "extra" in the
past week or two?
please forgive my lack of knowledge on it, i just see the result
if you can direct me, ill be happy to gather more info
i just noticed someone on centos list posted same
- rh

I'm getting a segfault when I yum update with rpmforge enabled as well on
CentOS 5.6.

Grant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20110726/92c4f483/attachment-0002.html>

[Fred Kienker]

-----Original Message-----
From: RobertH [mailto:roberth at abbacomm.net]
Sent: Tuesday, July 26, 2011 10:30 AM
To: users at lists.repoforge.org
Subject: [users] yum seg fault on repoforge extras
Dag
do you know why yum on centos4 is segfaulting on repoforge
"extra" in the past week or two?
please forgive my lack of knowledge on it, i just see the result
if you can direct me, ill be happy to gather more info
i just noticed someone on centos list posted same
- rh
_______________________________________________
users mailing list
users at lists.repoforge.org
http://lists.repoforge.org/mailman/listinfo/users

I have *exactly* the same problem. Currently only happening on one out
of 26 servers.

Best regards,

Fred

Fred Kienker

AT4B
"Advanced Technologies for Business"

This transmission may contain information that is privileged,
confidential and/or exempt from disclosure under applicable law. If you
are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution, or use of the information contained
herein (including any reliance thereon) is STRICTLY PROHIBITED. If you
received this transmission in error, please immediately contact the
sender and destroy the material in its entirety, whether in electronic
or hard copy format. Thank you.

[Fred Kienker]

-----Original Message-----
From: Dag Wieers [mailto:dag at wieers.com]
Sent: Tuesday, July 26, 2011 11:00 AM
To: Discussions regarding Repoforge for users
Subject: Re: [users] yum seg fault on repoforge extras

On Tue, Jul 26, 2011 at 8:30 AM, RobertH

Post by RobertH
do you know why yum on centos4 is segfaulting on repoforge

"extra" in

Post by RobertH
the past week or two?
please forgive my lack of knowledge on it, i just see the result
if you can direct me, ill be happy to gather more info
i just noticed someone on centos list posted same

I'm getting a segfault when I yum update with rpmforge

enabled as well

on CentOS 5.6.

Whatever the cause, yum segfaulting on any repository
metadata is a security problem, possibly exploitable. We are
looking at our side to find the cause (or a workaround). I do
not seem to be able to reproduce this as of yet.
Regardless someone should fill this as a potential
security-problem with the yum maintainers. I think they
should be very concerned :-/
--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/
[Any errors in spelling, tact or fact are transmission
errors] _______________________________________________
users mailing list
users at lists.repoforge.org
http://lists.repoforge.org/mailman/listinfo/users

Originally it was only one server. It appears the problem is spreading
to the rest of the servers.

Best regards,

Fred

Fred Kienker

AT4B
"Advanced Technologies for Business"

This transmission may contain information that is privileged,
confidential and/or exempt from disclosure under applicable law. If you
are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution, or use of the information contained
herein (including any reliance thereon) is STRICTLY PROHIBITED. If you
received this transmission in error, please immediately contact the
sender and destroy the material in its entirety, whether in electronic
or hard copy format. Thank you.