No matching activity found.
|Generate a key:|
<prompt>%</prompt> <userinput>gpg --full-gen-key</userinput>
gpg (GnuPG) 2.1.8; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Warning: using insecure memory!
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection? <userinput>1</userinput>
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) <userinput>2048</userinput> <co xml:id="co-pgp-bits"/>
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) <userinput>3y</userinput> <co xml:id="co-pgp-expire"/>
Key expires at Wed Nov 4 17:20:20 2015 MST
Is this correct? (y/N) <userinput>y</userinput>
GnuPG needs to construct a user ID to identify your key.
Real name: <userinput><replaceable>Chucky Daemon</replaceable></userinput> <co xml:id="co-pgp-realname"/>
Email address: <userinput><replaceable>email@example.com</replaceable></userinput>
You selected this USER-ID:
"<replaceable>Chucky Daemon <firstname.lastname@example.org></replaceable>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? <userinput>o</userinput>
You need a Passphrase to protect your secret key.
|2048-bit keys with a three-year expiration provide adequate protection at present (2013-12). <link xlink:href="http://danielpocock.com/rsa-key-sizes-2048-or-4096-bits"/> describes the situation in more detail.|
|A three year key lifespan is short enough to obsolete keys weakened by advancing computer power, but long enough to reduce key management problems.|
|Use your real name here, preferably matching that shown on government-issued <acronym>ID</acronym> to make it easier for others to verify your identity. Text that may help others identify you can be entered in the <literal>Comment</literal> section.|
|After the email address is entered, a passphrase is requested. Methods of creating a secure passphrase are contentious. Rather than suggest a single way, here are some links to sites that describe various methods: <link xlink:href="http://world.std.com/~reinhold/diceware.html"/>, <link xlink:href="http://www.iusmentis.com/security/passphrasefaq/"/>, <link xlink:href="http://xkcd.com/936/"/>, <link xlink:href="http://en.wikipedia.org/wiki/Passphrase"/>.|
|Protect the private key and passphrase. If either the private key or passphrase may have been compromised or disclosed, immediately notify <email>accounts@FreeBSD.org</email> and revoke the key.|
|Committing the new key is shown in <xref linkend="commit-steps"/>.|
|Kerberos and LDAP web Password for FreeBSD Cluster|
|The FreeBSD cluster requires a Kerberos password to access certain services. The Kerberos password also serves as the LDAP web password, since LDAP is proxying to Kerberos in the cluster. Some of the services which require this include:|
|To create a new Kerberos account in the FreeBSD cluster, or to reset a Kerberos password for an existing account using a random password generator:|
|<prompt>%</prompt> <userinput>ssh kpasswd.freebsd.org</userinput>|
|This must be done from a machine outside of the FreeBSD.org cluster.|
|A Kerberos password can also be set manually by logging into <systemitem class="fqdomainname">freefall.FreeBSD.org</systemitem> and running:|
|Unless the Kerberos-authenticated services of the FreeBSD.org cluster have been used previously, <errorname>Client unknown</errorname> will be shown. This error means that the <command>ssh kpasswd.freebsd.org</command> method shown above must be used first to initialize the Kerberos account.|
|Commit Bit Types|
|The FreeBSD repository has a number of components which, when combined, support the basic operating system source, documentation, third party application ports infrastructure, and various maintained utilities. When FreeBSD commit bits are allocated, the areas of the tree where the bit may be used are specified. Generally, the areas associated with a bit reflect who authorized the allocation of the commit bit. Additional areas of authority may be added at a later date: when this occurs, the committer should follow normal commit bit allocation procedures for that area of the tree, seeking approval from the appropriate entity and possibly getting a mentor for that area for some period of time.|
|src/, doc/ subject to appropriate review|
|doc/, ports/, src/ documentation|
No matching activity found.