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 compile to. 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 product.
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.