Custom Query (894 matches)

Hi,

After having set up certificate authentication (including multi-CA authentication, like I discussed on the mailing list), there is still one thing that bothers me (in addition to CRLs not being avalaible as emebedded python SSL support is now, but it is another matter) : text password does not seem to possibly be disabled - ever.

Wether I disable it in the bcfg2.conf on the server, or on the clients, even if certificate authentication works correctly (verified therebefore by setting a different password on the server and on the clients, whatever they are : connection indeed still works perfectly), the server issues me a :

"No authentication data presented Authentication Failure"

in its log. Well, as said, if I set some password, even if the server and the client ones do not tie in, I authenticate perfectly well anyway with certificates : well, yes - certificates _are_ authentication data (and valid ones are even legit).

I for one do not only want to authenticate using certificates, but even be sure passwords are never ever used : I don't need them, I don't want them. In the meantime this bug gets corrected (using Debian to evaluate bcfg2 for now, even with Debian Squeeze which is the recently frozen Testing, this will not be corrected anytime soon in the stable flavor of my favorite distro, so, I settled on this workaround for now), I decided I will use a very long and complex global password on the server, and a bogus one on the clients (in case one of them gets compromised, and the password is leaked, this password would be of no use whatsoever ; having to manage a bogus server password is a bugger nonetheless, though, as whatever its length, it reduces the server's thoughness against unwanted breakins, in respect with a valid certificate as the only way through) - but this should really be corrected, IMHO : "No authentication data presented" should only be answered if, indeed, none has been - and in the case of certificate authentication, well : more than some has actually been, as a far better one than a bad-ol' symetric password has indeed been presented (actually, a password is no kind of authentication, but rather an authorization mean, whereas a user name is an authentication mean, and a certificate associated with its private key is both - would one want to be precize : telling who somebody presents himself as, and if she is authorized to go through, those are two very distinct notions).

Please allow for certificate authentication to be sufficient, and for ditching any kind of text password use if one wants to (I concur with the idea that if neither a password, nor a certificate, nor anything has been presented, connection should be refused by default - other people might need systematic connection authorization, though, but I guess this should be the case for another explicit option, such as "always-allow = true").

Regards.

Some repos like debian backports are designed to be used selectively so a whitelist mode for packages in these repos could be quite useful. Behaving the opposite way to the blacklist does now.

Generated config for xxx.uspswy6.savvis.net in 0.267s
Client xxx.uspswy6.savvis.net reported state dirty
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib64/python2.4/threading.py", line 442, in __bootstrap
    self.run()
  File "/usr/lib64/python2.4/threading.py", line 422, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib/python2.4/site-packages/Bcfg2/Server/Plugins/Snapshots.py", line 70, in load_snapshot
    self.statistics_from_old_stats(metadata, data)
  File "/usr/lib/python2.4/site-packages/Bcfg2/Server/Plugins/Snapshots.py", line 88, in statistics_from_old_stats
    data = [False, False, unicode(entry.get('name'))] \
  File "/usr/lib/python2.4/site-packages/Bcfg2/Server/Plugins/Snapshots.py", line 25, in build_snap_ent
    desired.update([(key, unicode(entry.get(key))) for key in \
KeyError: 'Directory'