10:58 p.m.
Hey all I added a file for tracking FE3, Please also fill this in when
adding CVE's I coppied the fe4 file and went though it there is some issues
to be fixed in FE3 i've fixed some of them. and marked some needing fixing.
I have removed issues for packages not in FE3 cvs tree.
We have under a month to get FE3 up to scratch or support will be turned
off. I would like to see security only support for FE3 until legacy drops
support.
--
Dennis Gilmore, RHCE
Proud Australian
8:40 a.m.
>>>> "DG" == Dennis Gilmore
<dennis(a)ausil.us> writes:
DG> We have under a month to get FE3 up to scratch or support will be
DG> turned off.
Something sounds wrong with this. I mean, FE3 has all sorts of
problems including unfixable broken dependencies and somehow it's up
to us to meet some deadline for fixing problems there?
Not that there's anything wrong with fixing security issues in FE3,
but I don't understand why the onus is put entirely on us.
- J<
8:43 a.m.
>>>>> "DG" == Dennis Gilmore
<dennis(a)ausil.us> writes:
DG> We have under a month to get FE3 up to scratch or support will be
DG> turned off.
Something sounds wrong with this. I mean, FE3 has all sorts of
problems including unfixable broken dependencies and somehow it's up
to us to meet some deadline for fixing problems there?
Not that there's anything wrong with fixing security issues in FE3,
but I don't understand why the onus is put entirely on us.
Some of the broken dependencies can be fixed. The Onus is not entirely
on us. But the Onus is on those who want to to either Fix the issues
or get the maintainers to be active for there packages.
Dennis
9:28 a.m.
Am Montag, den 22.05.2006, 08:40 -0500 schrieb Jason L Tibbitts III:
>>>>> "DG" == Dennis Gilmore
<dennis(a)ausil.us> writes:
DG> We have under a month to get FE3 up to scratch or support will be
DG> turned off.
Something sounds wrong with this.
Slightly.
I mean, FE3 has all sorts of
problems including unfixable broken dependencies
Is it that bad?
and somehow it's up
to us to meet some deadline for fixing problems there?
No! Only those that are interested it it. (see below)
Not that there's anything wrong with fixing security issues in
FE3,
but I don't understand why the onus is put entirely on us.
The concept was round about this:
Security Team starts working. It should track the current releases (e.g.
FE4 and FE5) (no that was never written down anywhere -- that was
probably obvious).
There were people (dgilmore, probably others) that wanted to keep FE3
alive. Some other people didn't like the idea, but we sort of had a
compromise: If the security team (or only parts of it, e.g. dgilmore,
others) track FE3 probably and fix open issues in an acceptable amount
of time (e.g they get the package maintainers to fix their packages or
someone else like dgilmore and/or the security team fixes it) then we
leave FE3 open in "Maintenance state".
This was the proposal we agreed on (the last para is the important one
for this discussion):
=== EOL.
When a Fedora Core release reaches Maintenance state (such as Fedora
Core 3 reached when Fedora Core 5 Test 2 was released), the
corresponding release of Fedora Extras will also enter a Maintenance
state. In this state maintainers will be allowed to issue updates to
existing packages, but Maintainers are strongly urged to only issue
severe bugfix or security fixes. New software versions should be avoided
except when necessary for resolving issues with the the current version.
Branches for new packages in CVS are not created for Distributions
that are in Maintenance state. FESCo can approve exceptions of this rule
if there are good reasons for it. The official package maintainers are
urged to fix their packages also for Distributions that are in
Maintenance state. They should work hand in hand with the "Security
Response Team" in case they don't have access to older
distros anymore to test their updates.
When the Fedora Project drops support for a Fedora Core release the
corresponding Fedora Extras is also dropped -- read this as
"End-of-life, no new updates,support for that EOL distro will be removed
from the Extras buildsys".
The EOL Policy depends on the creation and a working Security Response
Team and especially the part of it that "will lend assistance as needed"
if the maintainer is unable to fix the package -- if that group does not
start working properly until June 15 2006 we'll send out a EOL for
Fedora Extras 3 -- means: "Packagers can still update things in cvs and
build updates for now, but the official state of Fedora Extras 3 is
'unsupported and End of Life'". In that case we'll try to improve for
FE4 and later.
Hope that clarifies some things.
CU
thl
--
Thorsten Leemhuis <fedora(a)leemhuis.info>
10:18 a.m.
>>>> "TL" == Thorsten Leemhuis
<fedora(a)leemhuis.info> writes:
[Broken dependencies]
TL> Is it that bad?
Well, there's plague, which depends on a version of createrepo newer
than what shipped in core. Core will never issue an update, so extras
stays broken. Maybe Legacy will ship an update and we can get
everything back together.
But there have been other busted dependencies for months now.
About maintaining FE3, I see the point; I was just confused. But
according to the CVE list that Dennis put together, FE3 is no worse
off than FE4 is so at this point we can fix FE3 by working on FE4.
The issues are mantis and thttpd; both has open issues even on FE5.
(I'd check bugzilla for status but it's still down.)
- J<
8:45 a.m.
Anyway, it looks like we can solve four CVEs by pushing the updated
mantis. Then we'll be left with nothing that isn't vulnerable in FE5,
although I'm sure there are packages in FE3 that were dropped before
FE5 that we'll need to track down. Anyone know of an easy way to get
a list of those?
- J<
9:35 a.m.
New subject: Mantis and "difficult" upgrades (Was: Fedora Extras 3)
A quick chat with the packager of mantis (which is responsible for
five open CVEs on FE3 and FE4) shows that updates to 1.0.3 are
forthcoming for FE5 (which should fix CVE-2006-1577) but there is no
clean update path for FE3 and FE4 due to schema changes. There are
supposedly some scripts which will do the necessary schema updates.
It looks like backporting anything would be unreasonable, although I
haven't looked closely at the source.
So, a dilemma:
1) Push a naive update and break systems, leaving the admins to run
the schema updates.
2) Run them automatically and hope they actually work.
3) Leave things as they are (insecure).
4) Work in earnest to try to backport patches or come up with our own
fixes.
The maintainer also suggested that we pull mantis from FE3, although
that can't do anything for existing installations. (He doubts there
are any.)
What to do?
- J<
10:11 a.m.
New subject: Mantis and "difficult" upgrades (Was: Fedora Extras 3)
A quick chat with the packager of mantis (which is responsible for
five open CVEs on FE3 and FE4) shows that updates to 1.0.3 are
forthcoming for FE5 (which should fix CVE-2006-1577) but there is no
clean update path for FE3 and FE4 due to schema changes. There are
supposedly some scripts which will do the necessary schema updates.
It looks like backporting anything would be unreasonable, although I
haven't looked closely at the source.
So, a dilemma:
1) Push a naive update and break systems, leaving the admins to run
the schema updates.
Not Good but probably fairly wise attach to the
announcement the need
for manual admin intervention. If the upgrade scripts do not work then
the admin should be prepared to fix things by hand.
2) Run them automatically and hope they actually work.
Bad if
it could break things badly. better to make sure that the admin
is aware of what is needed. Could be ok with sufficient testing
3) Leave things as they are (insecure).
Not good and another
reason to EOL FE3
4) Work in earnest to try to backport patches or come up with our
own
fixes.
May be best bet. though schema updates should be taken into
consideration. If i updated my FC3 or FC4 systems to FC5 there should
be a proper upgrade path.
The maintainer also suggested that we pull mantis from FE3, although
that can't do anything for existing installations. (He doubts there
are any.)
Hard to say without stats from mirrors
Id rather not pull it. Its very hard to get the info out to everyone
who may be intrested. I know that some people rebuild my extras rebuild
on Aurora. I guess they don't trust my builds but they use the SRPMS i
publish.
Dennis
10:36 a.m.
New subject: Mantis and "difficult" upgrades
>>>> "DG" == Dennis Gilmore
<dennis(a)ausil.us> writes:
DG> Bad if it could break things badly. better to make sure that the
DG> admin is aware of what is needed. Could be ok with sufficient
DG> testing
I looked at the mantis source and it seems to be coded to handle this
well. The login page (it's a bug tracker written in PHP) checks the
database schema version and, if outdated, sends you to an upgrade
page.
If the CVEs are serious enough, just pushing the update may be the
best course of action. Otherwise we can see if it's reasonable to run the update
snippet
in %post.
> 3) Leave things as they are (insecure).
DG> Not good and
another reason to EOL FE3
FE4 has precisely the same issue in this case, so it seems this is not
an option.
> 4) Work in earnest to try to backport patches or come up with
our
> own fixes.
DG> May be best bet.
It depends on the nature of the problem. It could require someone
knowledgeable in both the operation of Mantis and PHP programming.
Leaves me out.
- J<
6550
days inactive
6550
days old
security@lists.fedoraproject.org
8 comments
3 participants
participants (3)
-
Dennis Gilmore -
Jason L Tibbitts III -
Thorsten Leemhuis