(Cleanup information about the deprecated DSA keys)
 
(5 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 
This tutorial is about how to apply for a commit account for KDE so that you may change files (code, documentation files, art, etc.) in KDE's git and svn repositories.
 
This tutorial is about how to apply for a commit account for KDE so that you may change files (code, documentation files, art, etc.) in KDE's git and svn repositories.
  
== Read-only access to git/svn ==
+
== Read-only access to Git or Subversion ==
  
You can checkout code anonymously without an account.
+
All KDE repositories can be cloned or checked out anonymously, without needing any account.
  
 
== KDE Identity Account ==
 
== KDE Identity Account ==
  
In order to request code reviews with [[Infrastructure/Review_Board|Review Board]], you'll need a '''KDE Identity Account'''. Go to [https://identity.kde.org/ https://identity.kde.org/] and create an account if you don't have one already.
+
In order to submit merge requests with [[Infrastructure/GitLab|GitLab]], you'll need a '''KDE Identity Account'''.
  
When you register on identity.kde.org, you will need to enter your name and an e-mail address, which has to be your own (a normal address or a KDE Mail address). Of course, do not forget that '''this email address becomes public''' (at least in [http://websvn.kde.org WebSVN] and [http://quickgit.kde.org GIT]) so you will unfortunately get some spam as a result.
+
These can be registered using the self-service [https://identity.kde.org|KDE Identity] site. As part of this process, you will need to provide a name and email address, which has to be your own. Please note that these details '''will be made publicly visible on Gitlab''' once you have logged in there. You may therefore receive some spam as an unfortunate consequence of this.
  
Also note that this email address should be the same one that you use on [http://bugs.kde.org bugs.kde.org]. If you don't have an account in [http://bugs.kde.org bugs.kde.org], please create one so that it can be given usual developer rights. Closing bug reports with keywords in commit comments only works if the email address associated with your KDE Developer account and [http://bugs.kde.org bugs.kde.org] accounts match.
+
When selecting your username, please ensure you select something which has a relation to your real name.
  
After that, you must choose a username for your KDE Developer account between the suggestions presented to you. Please notice it is not possible to propose something else such as a nickname, as the username must be as close as possible to someone's real name.
+
'''A Developer Account is not needed to fork repositories and submit merge requests on Gitlab.'''
  
If you ask for a KDE email address one day, this will be the base for your address. For example: <tt>[email protected]kde.org</tt>. (Note, however, that KDE email addresses are not granted so easily anymore, as too many people have ranted with a KDE address and other people thought that it was the official position of the KDE Team. In the meantime, [http://www.kdemail.net KDE Mail] was created for if you need a permanent address.)
+
Also note that this email address should be the same one that you use on [http://bugs.kde.org bugs.kde.org]. If you don't have an account in [http://bugs.kde.org bugs.kde.org], please create one so that it can be given usual developer rights. Closing bug reports with keywords in commit comments only works if the email address associated with your KDE Developer account and [http://bugs.kde.org bugs.kde.org] accounts match.
 
 
== How to get read-write access to git/svn ==
 
 
 
After you obtained your KDE Identity, visit the [https://identity.kde.org/index.php?r=developerApplication Developer Application page] to apply for a KDE Developer Account.
 
  
== KDE Repositories ==
+
== How to get read-write access to Git (Gitlab) ==
  
To have write access to KDE's git and SVN servers, you have to use KDE's main git and SVN server. Anonymous git and SVN uses mirrors of this server. Note that SVN does not allow you to read from one server and write to another, while git does. For a tutorial on using KDE's git services, see [[Development/Git|this tutorial]].
+
Please note that a KDE Developer account is not needed to submit merge requests on Gitlab. This can be done by anyone who holds a KDE Identity account.
 +
In most cases people will be encouraged by existing developers to apply for a KDE Developer account, although it is not required.
  
To be able to write to files stored in KDE's git and SVN repositories, you need an account. An account is made up of a username (normally your family name), a password, an ssh key and an email address. The username is for getting in, the password and ssh keys are for authenticating and the email address for knowing who to contact if another developer wants to contact the account holder.
+
When you are ready to apply for a KDE Developer account, you should visit the [https://identity.kde.org/index.php?r=developerApplication Developer Application page] to submit your application.
  
A KDE commit account allows you to write to nearly anywhere in the KDE repositories with a few exceptions, such as the www module. (Of course, exceptions can be made for this as well.)
+
This form will ask you a series of questions, including ''Why do you want an account?'', where you can explain what you want to do with your future KDE Developer account, like for example developing a certain application, making documentations or being the team leader of a translation.
  
'''Note''': you can see the accounts in [http://websvn.kde.org/trunk/kde-common/accounts kde-common/accounts]. That is the list of all accounts. Yes, '''the account list is public''', for example on [http://websvn.kde.org WebSVN].
+
Also note that the form will ask you who has encouraged you to apply. They will also get an email to verify your request.
  
 
== Who Can Apply For a KDE Developer Account? ==
 
== Who Can Apply For a KDE Developer Account? ==
Line 43: Line 40:
 
The limitations are not there to exclude anyone - they are there to ensure that the maintenance of accounts remains reasonable.
 
The limitations are not there to exclude anyone - they are there to ensure that the maintenance of accounts remains reasonable.
  
Of course, to be clear: ''the KDE's sysadmins have the last word about whether or not to create a KDE SVN account for somebody''.
+
Of course, to be clear: ''the KDE's sysadmins have the last word about whether or not to create a KDE Developer account for somebody''.
 
 
== SSH ==
 
 
 
You need an SSH public key in order to access your KDE Developer account. If you already have one, you can skip the next subsection and go to [[#Setting up the SVN+SSH protocol|Setting up the SVN+SSH protocol]].
 
 
 
=== Generating the SSH keys ===
 
 
 
To be able to use your KDE Developer account with SSH, you need a SSH public key. Please notice that it is '''not''' a GPG (OpenPGP) key, which is completely unrelated!
 
 
 
The password in the sense of this documentation is the '''public key''' that you are creating.
 
 
 
For more information on how to create a pair of SSH keys, please refer to a [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keygen SSH documentation] or book.
 
 
 
The command to create a pair of keys is '''ssh-keygen''' and it requires the type of key you will create (RSA key; DSA are long deprecated).
 
 
 
To create a new pair of keys, use <syntaxhighlight lang="bash">ssh-keygen -t rsa</syntaxhighlight>
 
 
 
There is also a type called RSA1 which was used in version 1 of the SSH protocol. See the [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keygen ssh documentation] for more details.
 
 
 
You can then accept the default filename for your key ({{path|$HOME/.ssh/id_rsa}}). After that, a passphrase is asked. It is recommended that you do not leave it blank.
 
 
 
Now that you are finished generating your key pair, you will have two files: a private key and a public key. If you have accepted the default filename, they will be respectively {{path|$HOME/.ssh/id_rsa}} and {{path|$HOME/.ssh/id_rsa.pub}}.
 
 
 
The private key '''must''' remain secret, do not publish it to anyone under any circumstance.
 
 
 
The public key can be published and shall be sent when you are applying for a KDE Developer account.
 
 
 
You should also set up <tt>ssh-agent</tt> so you do not have to type the password every time you connect via SSH. There are several tutorials available explaining how to do this, for example [http://mah.everybody.org/docs/ssh this one]. [http://www.funtoo.org/Keychain Keychain] is a program that makes this task easier.
 
 
 
'''Note''': if you already have an ssh key, you can just use the existing key instead of creating a new one.
 
 
 
{{tip|
 
If you want to use SVN with SSH with another user than the one who created the keys, you need to copy <tt>$HOME/.ssh/id_rsa.pub</tt> and <tt>$HOME/.ssh/id_rsa</tt> to the other user's <tt>$HOME/.ssh</tt> directory.
 
 
 
You should probably also backup those files.
 
}}
 
 
 
=== Using DSA/DSS Keys ===
 
 
 
Please note that recent versions of OpenSSH won't allow you to use DSA format keys by default, as it considers them insecure.
 
If you have a DSA format key you would like to use, please generate and register a new RSA key. Nevertheless, as a temporary measure, KDE Infrastructure still permits the usage of DSA keys - but you'll need to enable usage of them locally, by adding the following line to <tt>~/.ssh/config</tt>:
 
<pre>
 
PubkeyAcceptedKeyTypes ssh-dss
 
</pre>
 
 
 
=== Setting up the SVN+SSH protocol ===
 
 
 
Once you created your key, you'll have to tell SSH that this one should be used for all connections to KDE sites. For SVN access, add the following lines to the <tt>~/.ssh/config</tt> file. Replace USERNAME with yours.
 
 
 
<pre>
 
Host *.kde.org
 
        User USERNAME
 
        IdentityFile ~/.ssh/id_rsa
 
</pre>
 
 
 
The linked IdentityFile must belong to the public key you send in when applying for the SVN account. But it is ''not'' the public key (<tt>*.pub</tt>).
 
 
 
=== Setting up the GIT protocol ===
 
 
 
Once you created your key, you'll have to tell SSH that this one should be used for all connections to KDE's git servers. For GIT access, add the following lines to the <tt>~/.ssh/config</tt> file. Because you always connect as user "git", you use that name for the entry User. You will be identified by the key that you use.
 
 
 
<pre>
 
Host *.kde.org
 
        User git
 
        IdentityFile ~/.ssh/id_rsa
 
</pre>
 
 
 
The linked IdentityFile must belong to the public key you send in when applying for the KDE account. But it is ''not'' the public key (<tt>*.pub</tt>).
 
 
 
== Apply for a KDE Developer account ==
 
 
 
Now you are ready to apply for a KDE Developer account. Go to [https://identity.kde.org/ https://identity.kde.org/] and create a KDE Identity Account if you don't have one already (see above for the details). Then visit the [https://identity.kde.org/index.php?r=developerApplication Developer Application page].
 
 
 
When applying for developer access you have to provide your public SSH key. This key will be added to your profile. You can always add more keys or delete keys you don't use anymore from your profile page on identity.kde.org.
 
 
 
The form also holds a field ''Why do you want an account?'', where you can explain what you want to do with your future KDE Developer account, like for example developing a certain application, making documentations or being the team leader of a translation.
 
 
 
Also note that the form will ask you who has encouraged you to apply. He or she will also get an email to verify your request.
 
 
 
== Updating An Existing KDE Developer Account ==
 
 
 
If you already have a KDE Developer account but want to update the ssh key, you should go to [https://identity.kde.org/ identity.kde.org] and change the keys in your profile.
 
 
 
== And Now? ==
 
 
 
After having sent the form and clicking the link in the email, you have to wait for the answer (typically within two or three days).
 
 
 
Once you have confirmation that your account has been created, you need to make sure that you push your git changes to [email protected]/<repository> instead of git://anongit.kde.org/<repository>
 
 
 
If the project(s) you are contributing to are hosted on KDE's Git infrastructure (which is the case now for most projects), the next steps are described in the [[Infrastructure/Git | Git]] page. If you want to contribute to projects which are still hosted on SVN, you find instructions for that on the [[Infrastructure/Subversion | SVN]] page
 
 
 
Please add your geographical location (what country are you in?) and other details at the [http://commit-digest.org/data/ Commit Digest data page] so that the Commit Digest can accurately reflect who is working where.
 

Latest revision as of 06:28, 30 June 2020

This tutorial is about how to apply for a commit account for KDE so that you may change files (code, documentation files, art, etc.) in KDE's git and svn repositories.

Read-only access to Git or Subversion

All KDE repositories can be cloned or checked out anonymously, without needing any account.

KDE Identity Account

In order to submit merge requests with GitLab, you'll need a KDE Identity Account.

These can be registered using the self-service Identity site. As part of this process, you will need to provide a name and email address, which has to be your own. Please note that these details will be made publicly visible on Gitlab once you have logged in there. You may therefore receive some spam as an unfortunate consequence of this.

When selecting your username, please ensure you select something which has a relation to your real name.

A Developer Account is not needed to fork repositories and submit merge requests on Gitlab.

Also note that this email address should be the same one that you use on bugs.kde.org. If you don't have an account in bugs.kde.org, please create one so that it can be given usual developer rights. Closing bug reports with keywords in commit comments only works if the email address associated with your KDE Developer account and bugs.kde.org accounts match.

How to get read-write access to Git (Gitlab)

Please note that a KDE Developer account is not needed to submit merge requests on Gitlab. This can be done by anyone who holds a KDE Identity account. In most cases people will be encouraged by existing developers to apply for a KDE Developer account, although it is not required.

When you are ready to apply for a KDE Developer account, you should visit the Developer Application page to submit your application.

This form will ask you a series of questions, including Why do you want an account?, where you can explain what you want to do with your future KDE Developer account, like for example developing a certain application, making documentations or being the team leader of a translation.

Also note that the form will ask you who has encouraged you to apply. They will also get an email to verify your request.

Who Can Apply For a KDE Developer Account?

Normally, any developer who has done some work on projects hosted by KDE can apply for a KDE Developer account.

Translators should get approval from their team leader so that they can organize how the work is being done in his/her team. Please mention the approval from the team leader when requesting the account.

Please also read the KDE commit policy. You must accept these rules when using your future KDE Developer account. Please also familiarize yourself with the KDE Code of Conduct which describes the social foundations within KDE.

Also please apply for an account only if you think that you will work on KDE for a somewhat longer time. If you know that you will only work for a couple of weeks and then never again, please consider not applying for a KDE Developer account but instead continue to send patches directly to developers.

The limitations are not there to exclude anyone - they are there to ensure that the maintenance of accounts remains reasonable.

Of course, to be clear: the KDE's sysadmins have the last word about whether or not to create a KDE Developer account for somebody.


This page was last edited on 30 June 2020, at 06:28. Content is available under Creative Commons License SA 4.0 unless otherwise noted.