Source string Read only

(itstool) path: note/para
Context English State
keyid-format 0xlong
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed
verify-options show-uid-validity
list-options show-uid-validity
cert-digest-algo SHA512
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
&lt;n&gt; = key expires in n days
&lt;n&gt;w = key expires in n weeks
&lt;n&gt;m = key expires in n months
&lt;n&gt;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></replaceable></userinput>
You selected this USER-ID:
"<replaceable>Chucky Daemon &lt;;</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=""/> 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=""/>, <link xlink:href=""/>, <link xlink:href=""/>, <link xlink:href=""/>.
Protect the private key and passphrase. If either the private key or passphrase may have been compromised or disclosed, immediately notify <email></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:
<link xlink:href="">Bugzilla</link>
<link xlink:href="">Jenkins</link>
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</userinput>
This must be done from a machine outside of the cluster.
A Kerberos password can also be set manually by logging into <systemitem class="fqdomainname"></systemitem> and running:
<prompt>%</prompt> <userinput>kpasswd</userinput>
Unless the Kerberos-authenticated services of the cluster have been used previously, <errorname>Client unknown</errorname> will be shown. This error means that the <command>ssh</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.
<emphasis>Committer Type</emphasis>
<emphasis>Tree Components</emphasis>
src/, doc/ subject to appropriate review
doc/, ports/, src/ documentation


No matching activity found.

Browse all component changes


English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: note/para
Source string location
String age
a year ago
Source string age
a year ago
Translation file
articles/committers-guide.pot, string 62