This package looks fine, but I would be extremely displeased if installing this
package modified my sshd_config file.  This is just a package that generates
some DNS records; it has no business messing about with an unrelated part of the
system.  Besides, I wouldn't install this package on every SSH server; I'd
instead  run it on my name server which has a rather more restricted SSHd
configuration that, frankly, nobody but me should ever touch.

It changes /etc/sshd/ssh_config not /etc/sshd/sshd_config. It only changes the
behaviour of the ssh client. 

    VerifyHostKeyDNS
             Specifies whether to verify the remote key using DNS and SSHFP
             resource records.  If this option is set to “yes”, the client
             will implicitly trust keys that match a secure fingerprint from
             DNS.  Insecure fingerprints will be handled as if this option was
             set to “ask”.  If this option is set to “ask”, information on
             fingerprint match will be displayed, but the user will still need
             to confirm new host keys according to the StrictHostKeyChecking
             option.  The argument must be “yes”, “no” or “ask”.  The default
             is “no”.  Note that this option applies to protocol version 2
             only.


I do see your point about not installing this package everywhere, and as such
enabling VerifyHostKeyDNS in the ssh client configuration is not very useful.

I choose to enable it so that I can generate sshfp records on the same machine
that I use to test the SSHFP records work properly.

Do you still think it is a problem to enable this?

The user will still be prompted for the new key, but an additional message
appears saying the key matches the DNS entry for it. Extra big warning banners
happen when you're being MITM'ed by someone redirecting your port 22 stream.

I don't understand why RedHat does not enable VerifyHostKeyDNS. It only adds to
security, at the expense of one DNS lookup. Especially with the first DNSSEC
TLD's being in full production (amonst them all of RIPE-NCC's reverse!)

My apologies; I misread the %post script.  But still, I don't personally think
it's appropriate for a package to mess with the config files of a mostly
unrelated pacakge.  Perhaps if the package installed some library necessary that
enabled the ssh client to use this functionality, but even that is questionable.
 (Witness the problems with Spamassassin automatically enabling some
functionality when certain Perl modules are installed.  In that case there isn't
even config file munging and there is still a general dislike of this kind of
action at a distance.)

Perhaps someone else will have a differing opinion.

I don't really know why this isn't enabled by default; perhaps the additional
DNS lookup is problematic.

Okay. I guess I agree this discussion should move to the openssh-clients package.

* Mon Sep 25 2006 Paul Wouters <paul> - 1.0.6-2
- Don't change VerifyHostKeyDNS in /etc/ssh/ssh_config anymore

It looks like you're in the process of updating the package; the spec link in
comment 1 shows version 1.1.0-1.  Let me know when you have a new package ready.

That's corect. I found a bug in generating the sshfp records.

Spec URL: ftp://ftp.xelerance.com/sshfp/sshfp.spec
SRPM URL: ftp://ftp.xelerance.com/sshfp/sshfp-1.1.0-1.src.rpm

* Tue Sep 26 2006 Paul Wouters <paul> - 1.1.0-1
- Mistakingly ran the sha1() call on the uuencoded keyblob, which
  generated wrong SSHFP records.

* Mon Sep 25 2006 Paul Wouters <paul> - 1.0.6-2
- Don't change VerifyHostKeyDNS in /etc/ssh/ssh_config anymore

* Tue Sep 19 2006 Paul Wouters <paul> - 1.0.6-1
- Initial release for Fedora Extras

Sorry for taking so long to respond.

The only thing I have to say now is that you need to modify %description to
match the current non-ssh_config-modifying behavior of the package.  But you can
do that when you check it in.

Now I just need to figure out how to get my DNS configured to hand out these keys.

* source files match upstream:
   7bceb2240c34cb5929d931cd248e9e35  sshfp-1.1.0.tar.gz
* package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* dist tag is present.
* build root is correct.
* license field matches the actual license.
* license is open source-compatible. License text included in package.
* latest version is being packaged.
* BuildRequires are proper (none)
* %clean is present.
* package builds in mock (development, x86_64).
* package installs properly
* rpmlint is silent.
* final provides and requires are sane:
   sshfp = 1.1.0-1.fc6
  =
   /usr/bin/python
   openssh-clients >= 4
   python-dns
* %check is not present; no test suite upstream.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* no scriptlets present.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.

APPROVED

Thanks :)

Just concatenate the output of sshfp -a -s yourdomain.com to your zone file :)