If `sshkey` config option is set, then osc prefers it over password auth.
If `sshkey` config option is not set and the server supports both basic
and signature auth, basic auth is used and ssh key is NOT auto-detected.
Users who want to use ssh auth with ssh key auto-detection can now leave
the `pass` config option empty to trigger ssh key auto-detection.
The ssh-key autodetection picks the first key that matches:
- key loaded to ssh-agent (`ssh-add -l`) that has a public key in ~/.ssh
- ~/.ssh/{id_ed25519,id_rsa}
It is also recommended to use Obfuscated or Plaintext credentials manager.
Please be aware that storing passwords using these credentials managers
is unsafe, because they're stored in plain text on disk.
Example:
[<apiurl>]
user=<username>
pass=
# ssh key is auto-detected because `pass` is empty
sshkey=
credentials_mgr_class=osc.credentials.ObfuscatedConfigFileCredentialsManager
When using ssh keys from gpg, there are no private key files on
disk. The public keys are available from "ssh-add -L". Conveniently,
users store the public keys in some ".pub" file under ~/.ssh
(see e.g. https://serverfault.com/questions/906871/force-the-use-of-a-gpg-key-as-an-ssh-key-for-a-given-server;
this is also necessary to use IdentityFile= in ssh itself).
Thus public key files can't be ignored any more in list_ssh_dir_keys().
"ssh-keygen -Y sign" works nicely with a public key file if the agent
has access to the private key.
Emojis were broken due to this commit.
The revert causes a change in behavior:
"\n" no longer gets resolved to a newline.
It is suggested to do the following instead:
$ osc <command> ... -m "first line
second line"
This reverts commit 16fda3115c.
* src/noarch rpm packaages needs to be stored in scheduler architecture to avoid
conflicts of the multiple versions
* avoid removal of every downloaded file
There seem to be a bug in how GitHub generates archives.
"Format:" and "$" characters get removed from the version string,
setting it to:
version = "%(describe:tags=true)"
Fixes the following error:
```
% osc
Traceback (most recent call last):
File "/usr/bin/osc", line 45, in <module>
r = babysitter.run(osccli)
File "/usr/lib/python3.10/site-packages/osc/babysitter.py", line 67, in run
return prg.main(argv)
File "/usr/lib/python3.10/site-packages/osc/cmdln.py", line 341, in main
self.postoptparse()
File "/usr/lib/python3.10/site-packages/osc/commandline.py", line 137, in postoptparse
if self._get_canonical_cmd_name(self.args[0]) == "help":
IndexError: list index out of range
```
* init command is working inside of a git repository
* downloadassets command fetches references assets from build description
* checkout is cloning from git
This changes the code back to retrying up to 5 times for old
python version 2.6.6-2.7.9. The complete backport of the basic auth
changes clutters up the code way to much for such a little gain.
(This basically reverts commit 326abe0c8b)
It is possible that the self._pwfunc() call returns a callable. For
instance, if the keyutils.osc.OscKernelKeyringBackend is configured
in the oscrc. Hence, check in credentials._LazyPassword.__str__
if the returned password is a callable and, if so, call it. Moreover,
a deprecation warning is printed. Eventually, this compat code will
be removed again.
This is a follow-up commit for commit
784d330f20 ("Only prompt for a password
if the server asks for it") (actually, it is a regression that was
not caught during the review...).
Only ask for a password if it is really needed for authentication.
The new lazy password approach is much smarter than the old callable
hack. That's why we deprecate returning a callable from
AbstractCredentialsManager.get_password. The current compatibility code
for a callable will be removed in the near future.
Minor nitpick: actually it would have been "cleaner" to introduce a new
subclass like an AbstractLazyPasswordCredentialsManager that encapsulates
the lazy password behavior. Currently, if, for instance, a credentials
manager is always non-lazy it would just override get_password but still
inherits the abstract (and unused) _get_password method.
In many cases the session cookie is already available, so there
is no need to ask for a password. To make this work with the
python authentication implementation, we add a small proxy object
for the password and only ask the credential manager if the
stringify method is called.
This approach also makes it possible to offer a non-password based
authorization type if the server allows multiple authentication
methods.
