The up2date server side code is not publically available. Therefore, users
of this service cannot completely trust the files being delivered to them.
As Red Hat's PR has been quick to point out, closed source products
should not be trusted in security-sensitive environments. Without access to
the up2date server side code a user cannot completely trust this updating
service. Signature checking on the client side helps, but it doesn't ensure
that red hat is not delivering subtely different packages than the ones
found on their normal ftp site to the up2date users. Afterall, they're the
same sigs. Users of up2date have to take it on faith that the packages
being sent to them are the same ones that the srpms on the ftp site
Having the server side code does not guarantee that the server running at
red hat is sending the same packages but it allows the user the option of
running their own local up2date server w/packages they compile from either
the srpms that red hat provides (after the user checks these packages) or
packages of their own making. This would allow those people in
security-sensitive environments to make trusted use of red hat's up2date
Users can verify packages via gpg sigs ( if you know how to fake gpg
sigs, please file another bug report against gpg).
They can also validate the packages via md5sums, file size, binary diffs,
by examining the contents of the packages, and the source rpms.
The server code is currently not distributed in any form.
Reclassifying as a enhancement request.