Suggestion: password as an argument

[bluesman80]

Currently in order to use the tool with Bitbucket, one needs to save the app password to the settings.yml file. For security concerns it'd be better to be able to pass it as an argument to the program. It will come in handy when running a Jenkins job.

I'm new to this .NET core thing, so please let me know if I'm missing anything here.

Thank you.

[christianspecht]

IMO saving an app password in a settings file is not that bad, because app passwords can be revoked anytime and have only limited permissions. But I see your point.

However: SCM Backup supports backing up from multiple source code hosters and backing up multiple users/teams per source code hoster.
--> In order for your suggestion to work, it must be possible to pass multiple passwords as an argument.

Let's use this settings file as an example, which contains two sources:

sources:

  - title: some_title
    hoster: github
    type: user
    name: your_user_name

  - title: another_title
    hoster: github
    type: org
    name: your_org_name

The title is unique across the whole config file, so the first idea that comes to my mind is: pass title and app password as key-value pairs. Something like:

scmbackup --passwords some_title;password1|another_title;password2

Do you have a good idea for a sane format for this?

---

Another idea: since your use case is a build server, how about using environment variables instead? I never used Jenkins, but this project is built via AppVeyor, which supports defining environment variables in an admin screen which are available at build runtime. I suppose Jenkins has a similar feature as well.

Possible variable names: scmbackuppasswordTITLE, e.g. scmbackup_password_some_title, scmbackup_password_another_title

[bluesman80]

Hi @christianspecht Thanks for your reply.

On a second thought, I think you are right about that putting an app password into a settings file is not that bad.

However, it would still be a good idea to make this improvement in a sane way, as you expressed. Hence, it should not adversely affect the user friendliness of the tool and at the same time it should allow the user to keep the passwords in a safer way.

For the first part of your comment, the format you suggested seems OK to me. I cannot come up with a better format.

For the second part of your comment, I agree with you. There is a plugin in Jenkins for binding the pre-saved credentials to environment variables temporarily. By temporarily I mean that the credentials are only available as environment variables while the job runs. Moreover, they are masked in the logs. The plugin allows the user to define the name of the variables per job, therefore if we can put the variable names into the settings file and make the program read them from the environment it would be safer and convenient at the same time.

[christianspecht]

This is now implemented in version 1.4.0.

Note that I still don't really like the idea of passing the arguments via command line, IMO the format looks messy.

So I only implemented the alternative with the environment variables, here's the documentation: https://docs.scm-backup.org/en/1.4/config/#authentication

[bluesman80]

Thank you. I just tested it with a Jenkins (ver. 2.204.1) job running on Ubuntu 18.04.2 LTS (GNU/Linux 4.15.0-1058-aws x86_64) and it works.