Ticket #982 (closed task: fixed)

Opened 16 months ago

Last modified 16 months ago

Fedup does not verify source. Treat https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=877623 as a Fedora 18 blocker

Reported by: sundaram Owned by:
Priority: major Keywords:
Cc: jreznik Blocked By:
Blocking:

Description

phenomenon

Fedup does not verify source. This wasn't a critical issue while Anaconda based media upgrades were still supported but Anaconda has completed removed all upgrade functionality entirely and delegated it to fedup which does not provide a secure method to perform the upgrade leaving Fedora 18 as a release which has no supported and secure upgrade path.

related discussion:

https://lists.fedoraproject.org/pipermail/devel/2012-December/175350.html

background analysis

It is true that preupgrade (https://bugzilla.redhat.com/show_bug.cgi?id=509338) nor anaconda itself (https://bugzilla.redhat.com/show_bug.cgi?id=998) has verified the source and it has been argued that Fedup not doing it isn't a regression. While technically correct, the lack of media/ISO based upgrade *is* a regression and has a unaccepted side effect

implementation recommendation

Mark 877623 as a release blocker and make sure this is fixed before we release Fedora 18. Alternatively support ISO based upgrade. I am not sure why Fedora QA didn't do so.

yum does provide a secure method of upgrading to Fedora 18 however Fedora has deemed it unsupported and that means we cannot recommend it to new users.

Change History

comment:1 Changed 16 months ago by mmaslano

Blockers should be solved on Go/No?-go meeting. I didn't find in the blocker process any note about fesco. Anyway we accepted anaconda/fedup as is, so we can't change our position now.

comment:2 Changed 16 months ago by sundaram

Your response does not address the issue. Not everyone can attend the go/no go meeting when it is running and FESCo is ultimately responsible for all technical decisions in Fedora. FESCo as a committee can and does change position if it is deemed suitable.

comment:3 Changed 16 months ago by jreznik

FESCo already agreed not to block on signature checking, and to postpone it to F19 on 2012-12-05 meeting as part of ticket https://fedorahosted.org/fesco/ticket/960. Media based update should be available (--device argument of fedup-cli).

From the 2012-12-05 meeting: "AGREED: Do not block on fedup signature checking (not a regression) (+:7, -:0, 0:0)"

comment:4 Changed 16 months ago by jreznik

  • Cc jreznik added

comment:5 Changed 16 months ago by wwoods

media upgrades

lack of media/ISO based upgrade *is* a regression and has a unaccepted side effect

You appear to be misinformed - fedup supports upgrade from media. See the changelog for fedup-0.7.1:

- Add support for upgrades from media (--device)

ISO support is buggy at the moment but that should be fixed in 0.7.2.

"security"

Fedup does not verify source ... does not provide a secure method to perform the upgrade

This is a false equivalence.

By itself, an old-style install from media isn't "secure" either. Verifying the ISO checksum only ensures that the data isn't corrupted - it provides no security.

To actually verify that the ISO is authentic and intact, the user has to manually follow the steps at https://fedoraproject.org/en/verify - i.e.:

  • Get the F18 GPG key, add it to keyring
  • Fetch the correct CHECKSUM file for the given image + arch
  • Verify the CHECKSUM file, check that the key ID matches the Fedora Project key ID
  • Verify the image checksum against the CHECKSUM file

Once you've verified the ISO/media, you can use fedup to install from it.

This is the same as how things work with anaconda-based upgrades.

future work

The heart of these problems is this: there's no trust relationship between individual Fedora releases.

As discussed in bug 877623 we can't really solve these problems properly without deciding on some distro-wide policy for whether and how F17 systems should obtain the F18 key and establish trust for it.

We could accomplish this any number of ways. For example, the F18 key could be released in an F17 update. Updates are signed, which means the F18 key can be assumed to be authentic and trustworthy.

That's just one idea; there's more discussion of this in bug 877623.

But until such a policy exists this problem is not fixable.

comment:6 Changed 16 months ago by sundaram

It wasn't really false equivalence since one could perform the steps indicated and verify the authenticity and without support for media based upgrades, we wouldn't have that ability at all but I understand your point.

I appear to have a older version for some reason and yes, I can confirm, 0.7.1 appears to have media support (will test it later). If .2 adds support for ISO based upgrades (hopefully before F18 release), that leaves us with the roughly same situation as before (without a graphical update UI but that isn't very relevant here). Therefore, I am closing this. Thanks Will Woods.

comment:7 Changed 16 months ago by sundaram

  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.