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.

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.

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)"

=== 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 [https://bugzilla.redhat.com/show_bug.cgi?id=877623#c23 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 [https://bugzilla.redhat.com/show_bug.cgi?id=877623#c23 bug 877623].

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

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.

I just noticed that all this playing with KeePassX has been done using provenpackager privileges, since limb is not present in any of sections of committers/administrators of
https://admin.fedoraproject.org/pkgdb/package/rpms/keepassx/

Replying to [comment:8 germano]:

I just noticed that all this playing with KeePassX has been done using provenpackager privileges, since limb is not present in any of sections of committers/administrators of
https://admin.fedoraproject.org/pkgdb/package/rpms/keepassx/

Perhaps you meant that comment for https://fedorahosted.org/fesco/ticket/1569 ?