https://wiki.archlinux.org/api.php?action=feedcontributions&user=Ritka&feedformat=atomArchWiki - User contributions [en]2024-03-29T06:30:21ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Talk:Dwm&diff=695617Talk:Dwm2021-09-13T12:22:49Z<p>Ritka: /* ccache issues */ re</p>
<hr />
<div>== ccache issues ==<br />
<br />
If [[ccache]] and [[GCC]] are used to compile dwm (and seemingly any other suckless software - I tested [[st]]), then, if {{ic|config.h}} is modified, the cached version of it appears to still be used in subsequent compilations.<br />
<br />
To reproduce:<br />
* Install and configure ccache as per [[ccache#Enable for command line]].<br />
* Set [[GCC]] as the default C compiler - This issue doesn't appear to occur with [[clang]].<br />
* Clone dwm.<br />
git clone https://git.suckless.org/dwm<br />
* Compile normally, once.<br />
$ make<br />
* Reset the state of the repo.<br />
$ git checkout . && git clean -fd<br />
* For argument's sake, create an invalid {{ic|config.h}}.<br />
$ cp config.def.h config.h<br />
$ echo "#error This should cause compilation to fail!" >> config.h<br />
* Compile again.<br />
$ make<br />
<br />
For me, this is the point at which it succeeds, when it shouldn't. If I add a similar error to, say, {{ic|dwm.c}}, only then does it recognize the change made to {{ic|config.h}}.<br />
<br />
The [https://ccache.dev/manual/4.4.html#_handling_of_newly_created_header_files ccache documentation] offers a possible explanation for this behavior:<br />
<br />
"There is a catch with the direct mode: header files that were used by the compiler are recorded, but header files that were not used, but would have been used if they existed, are not. So, when ccache checks if a result can be taken from the cache, it currently can’t check if the existence of a new header file should invalidate the result. In practice, the direct mode is safe to use in the absolute majority of cases."<br />
<br />
Some action should be taken to protect users from this, such as:<br />
* Resolving this somehow upstream (the issue may be resolvable with a patch to the {{ic|Makefile}}).<br />
* Documenting this pitfall on all of the relevant [https://wiki.archlinux.org/title/Category:Suckless Suckless] pages.<br />
* Disabling ccache in all of the relevant [[PKGBUILD|PKGBUILDs]].<br />
<br />
[[User:CodingKoopa|CodingKoopa]] ([[User talk:CodingKoopa|talk]]) 18:26, 10 September 2021 (UTC)<br />
<br />
: To me this seems more like an issue of ccache and not so much of dwm. I am not familiar with ccache, but the [https://ccache.dev/manual/4.4.html#_handling_of_newly_created_header_files documentation] seems to suggest some ways of handling these cases within ccache, i.e. setting the sloppiness or create the headerfiles earlier. In general I think it would be better to resolve this isssue for ccache in general and not for every single project that uses a config.h . Maybe mention these issues on the [[ccache]] page to avoid bloating the suckless pages.<br />
:<br />
: --[[User:Ritka|Ritka]] ([[User talk:Ritka|talk]]) 12:22, 13 September 2021 (UTC)</div>Ritkahttps://wiki.archlinux.org/index.php?title=Laptop/Lenovo&diff=576315Laptop/Lenovo2019-06-24T11:02:56Z<p>Ritka: /* L series */ Added ThinkPad L460</p>
<hr />
<div>[[Category:Lenovo]]<br />
[[ja:ノートパソコン/Lenovo]]<br />
{{Laptops navigation}}<br />
{{Related articles start}}<br />
{{Related|ThinkPad docks}}<br />
{{Related articles end}}<br />
<br />
== IBM/Lenovo ==<br />
<br />
=== ThinkPad ===<br />
<br />
==== Edge series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo ThinkPad Edge E330]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad Edge E335]] || NA || Yes || Yes || Yes || Yes || NA || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad Edge E420s || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || SDcard (Yes), Webcam (Yes), Trackpoint (No) || <br />
|-<br />
| [[Lenovo ThinkPad Edge E430]] || Yes || Yes || Yes* || Yes* || Not tested || Yes || NA || NA || SD card (yes) || <br />
|-<br />
| [[Lenovo ThinkPad Edge E455]] || 2015.04.01 || Yes* || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad Edge E470 || 2017.09.01 || Yes || Yes || Yes || Yes || Not tested || NA || NA || trackpoint (yes) ||<br />
|-<br />
| Lenovo ThinkPad Edge E530 || Yes || Yes || Yes* || Yes* || Yes || Yes || NA || NA || SD card (yes), Finger Print (yes) || E530 without fingerprint reader can be equipt with one.<br />
|-<br />
| Lenovo ThinkPad Edge E531 || Yes || Yes || Yes || Yes || Yes* || Yes || Yes || NA || SD card (yes), Touch Pad/Trackpoint (yes), Webcam (yes) || WiFi only works with {{Pkg|broadcom-wl-dkms}}<br />
|-<br />
| Lenovo ThinkPad Edge E540 || 2015.08.01 || Yes || Yes || Yes || Yes || Yes || Yes* || NA || SD card (yes), Finger Print (yes), touch pad and trackpoint (yes), Webcam (yes) || <br />
|-<br />
| Lenovo ThinkPad Edge E545 || NA || Yes || Yes || Yes || Yes* || Not tested || Yes || NA || SD card (yes), touch pad and trackpoint (yes) Webcam (yes) || wifi works only with {{Pkg|broadcom-wl-dkms}}<br />
|-<br />
| Lenovo ThinkPad Edge E580 || 2018.05.01 || Yes || Yes || Yes || Yes || Yes || Yes || NA || Fingerprint sensor doesn't work because of proprietary firmware || ||<br />
|-<br />
|}<br />
<br />
==== E series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo ThinkPad E485 || 2018-10-01 || Yes || Yes || Yes || Yes || Yes || Yes || N/A || || Missing IVRS map in ACPI Table, add <code>amd_iommu=pt ivrs_ioapic[32]=00:14.0</code> in [[kernel parameters]]. In order to get X to work correctly, add <code>iommu=soft</code> in [[kernel parameters]] (Linux 4.20 only). In order to get microsd (SDHCI) working, <code>echo 'options sdhci debug_quirks2="0x8000"' > /etc/modprobe.d/sdhci.conf</code> and change module load order <code>MODULES=(sdhci sdhci_pci)</code> in <code>/etc/mkinitcpio.conf</code> (line 7). Don't forget to run <code>mkinitcpio -p linux</code> afterwards.<br />
|-<br />
| Lenovo ThinkPad E585 || 2018-11-01 || Yes || Yes || Yes || Yes || Yes || Yes || N/A || || Missing IVRS map in ACPI Table, add <code>amd_iommu=pt ivrs_ioapic[32]=00:14.0</code> in [[kernel parameters]]. In order to get X to work correctly, add <code>iommu=soft</code> in [[kernel parameters]] (Linux 4.20 only). In order to get microsd (SDHCI) working, <code>echo 'options sdhci debug_quirks2="0x8000"' > /etc/modprobe.d/sdhci.conf</code> and change module load order <code>MODULES=(sdhci sdhci_pci)</code> in <code>/etc/mkinitcpio.conf</code> (line 7). Don't forget to run <code>mkinitcpio -p linux</code> afterwards. Bluetooth doesn't work until a suspend/resume cycle occurs.<br />
|-<br />
|}<br />
<br />
==== L series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo ThinkPad L380 Yoga]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Trackpoint*, Fingerprint reader ||<br />
|-<br />
| Lenovo ThinkPad L420 || Yes || Yes || Yes || Yes || Yes || Not tested || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad L430 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Trackpoint* ||<br />
|-<br />
| Lenovo ThinkPad L440 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Trackpoint (Touchpad cannot be disabled, as mouse buttons are shared with Trackpoint), Fingerprint reader, SD Card Reader ||<br />
|-<br />
| Lenovo ThinkPad L460 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || Trackpoint, Fingerprint reader, SD Card Reader ||<br />
|-<br />
| Lenovo ThinkPad L520 || 2018.09.01-x86_64|| Yes || Yes || Yes || Yes || Not tested|| Not tested|| Not tested|| Not tested ||<br />
|-<br />
| Lenovo ThinkPad L530 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Trackpoint*, Fingerprint reader ||<br />
|-<br />
| Lenovo ThinkPad L560 || Yes || Yes || Yes || Yes || Yes || Not tested || Not tested || NA || Trackpoint ||<br />
|-<br />
|}<br />
<br />
==== A series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo ThinkPad A485 || 2018.12 || Yes || Yes || Yes || Yes || Yes || Yes || NA || Touch Pad/Trackpoint (yes), Webcam (yes) || bluetooth does not work when activating [[Laptop Mode Tools]] <code>runtime-pm</code> module<br />
|}<br />
<br />
==== P series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo ThinkPad P50]] || 2016.04 || Yes || Yes || Yes || Yes || Yes || Suspend working, hibernate not tested || NA || SD card (Yes), Webcam (Yes), Fingerprint Reader ({{AUR|libfprint-vfs0090-git}}), || Wifi requires Kernel 4.3.3+ <br />
|-<br />
| [[Lenovo ThinkPad P70]] || 2016.04 || Yes || Yes || Yes || Yes || Yes || Suspend working, hibernate not tested || NA || SD card (Yes), Webcam (Yes), Fingerprint Reader (No), || Wifi requires Kernel 4.3.3+ <br />
|-<br />
| Lenovo ThinkPad P51 || Unknown || Yes || Yes || Yes || Yes || Yes || Yes || Yes (No GNSS/GPS) ||<br />
* Working: SD card, Webcam, Express card, Smartcard reader, Fingerprint Reader ({{AUR|libfprint-vfs0097-git}})<br />
* Not working: TPM, Color calibrator, UEFI flash <br />
|| HDMI audio requires nvhda module<br />
|-<br />
| [[Lenovo ThinkPad P52]] || 2018.09 || Yes || Yes || Yes || Yes || Unknown || Suspend working, hibernate not tested || NA || Touchpad (No) ||<br />
|-<br />
| [[Lenovo ThinkPad P1]] || 2018.12 || Yes || Yes || Yes || Yes || Yes || Suspend working, hibernate not tested || NA || Webcam (Yes), multi-monitor (yes)|| <br />
|-<br />
| [[Lenovo ThinkPad P52s]] || 2019.02 || Yes* (See Remarks) || Yes || Yes || Yes || Yes || Suspend (Yes), Hibernate (Yes) || Not tested || Webcam (Yes), Multi-monitor (Yes), Card Reader (Yes), Smartcard Reader (Yes), NFC (No, [https://github.com/nfc-tools/libnfc/issues/455 see this]), Fingerprint (No, [https://forums.lenovo.com/t5/Linux-Discussion/Thinkpad-T580-Synaptics-Metallica-MIS-Touch-Fingerprint-Reader/m-p/4057745 see this])|| *Intel graphics needs to be specified in the Xorg config for Xorg to work, see [[Lenovo ThinkPad P52s]]<br />
|}<br />
<br />
==== T series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad T60 || Yes || Yes || Yes || Yes || Yes || Yes || ? || NA || ||<br />
|-<br />
| IBM ThinkPad T60p || Yes || Yes || Yes || Yes || Yes || Yes || ? || NA || ThinkFinger ||<br />
|-<br />
| [[IBM ThinkPad T61]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || || ||<br />
|-<br />
| IBM ThinkPad T61p || Yes || Yes || Yes || Yes || Yes || Yes || NA || || ||<br />
|-<br />
| [[Lenovo ThinkPad T400]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T400s]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| Lenovo ThinkPad T410 || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T420]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Card reader tested, no Fingerprint scanner||<br />
|-<br />
| [[Lenovo ThinkPad T420s]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || Card Reader ||<br />
|-<br />
| [[Lenovo ThinkPad T430]] || Yes || Yes || Yes || Yes || Yes || Yes* || Yes* || Not tested || ||<br />
|-<br />
| [[#Lenovo ThinkPad T440p|Lenovo ThinkPad T440p]] || Yes || Yes || Yes || Yes || Yes || Yes* || NA || NA || Card Reader || See below<br />
|-<br />
| [[Lenovo ThinkPad T440s]] || Yes || Yes || Yes || Yes || Yes* || ? || Yes || ? || || See wiki page for more details about wireless<br />
|-<br />
| [[Lenovo ThinkPad T450s]] || 2015.10.01 || Yes || Yes || Yes || Yes || Yes || ? || NA || SD Card reader; fingerprint scanner|| <br />
|-<br />
| [[Lenovo ThinkPad T460s]] || Yes || Yes || no beep || Yes || Yes || Yes || ? || NA || SD Card reader|| <br />
|-<br />
| [[Lenovo ThinkPad T25]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD Card reader; fingerprint scanner; Touchscreen|| <br />
|-<br />
| [[Lenovo ThinkPad T470]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD Card reader; fingerprint scanner|| <br />
|-<br />
| [[Lenovo ThinkPad T470s]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD Card reader; fingerprint scanner|| <br />
|-<br />
| [[Lenovo ThinkPad T480]] || 2018.07.01 || Yes || Yes || Yes || Yes || Yes || ? || NA || Thunderbolt 3 (USB-C); SD Card reader; fingerprint scanner|| <br />
|-<br />
| [[Lenovo ThinkPad T480]] || 2018.07.01 || Yes || Yes || Yes || Yes || Yes || ? || NA || Thunderbolt 3 (USB-C); SD Card reader; fingerprint scanner|| <br />
|-<br />
| [[Lenovo ThinkPad T490]] || Yes || Yes || Yes || ? || Yes || ? || Yes || NA || Thunderbolt 3 (USB-C); SD Card reader || Some problems with touchpad<br />
|-<br />
| Lenovo ThinkPad T500 || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T520]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T530]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T550]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || DisplayPort ||<br />
|-<br />
| Lenovo ThinkPad T560 || Yes || Yes || Yes || Yes || Yes || Yes || Yes* || NA || MiniDP; Fingerprint scanner; Intel + Nvidia GPU; Card Reader || See special notes for the hardware specifications of this test device<br />
|-<br />
| [[Lenovo ThinkPad T570]] || Yes || Yes || Yes || Yes || Yes || ? || Yes* || NA || not yet fully tested || <br />
|-<br />
| Lenovo ThinkPad T580 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD Card Reader is supported; [https://forums.lenovo.com/t5/Linux-Discussion/Thinkpad-T580-Synaptics-Metallica-MIS-Touch-Fingerprint-Reader/m-p/4057745 Fingerprint reader is not supported] || Tested on ''2 May 2018'' (with ''Linux 4.16.5'')<br />
|}<br />
<br />
==== W series ====<br />
{{HCL/Laptops table header}}<br />
|-<br />
| Lenovo ThinkPad W510 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Yes), Webcam (Yes), Touchscreen (Yes), Fingerprint Reader (Not tested) || Tested April 2017 / Linux 4.10.8<br />
|-<br />
| Lenovo ThinkPad W530 || 2016.03 || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Yes), Webcam (Yes), Fingerprint Reader (Yes) || Tested April 2018 / Linux 4.15.15<br />
|-<br />
| Lenovo ThinkPad W540 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Yes), Webcam (Yes), Fingerprint Reader (Yes) || Tested April 2017 / Linux 4.10.8<br />
|-<br />
| Lenovo ThinkPad W541 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || SD card (Yes), Webcam (Yes), Fingerprint Reader (Not tested) || Tested August 2018 / Linux 4.17.12<br />
|-<br />
| Lenovo ThinkPad W550s || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Yes), Webcam (Yes), Fingerprint Reader (Yes) || Tested April 2018 / Linux 4.15.15<br />
|-<br />
|}<br />
<br />
==== X series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| [[IBM ThinkPad X60s]] || Yes|| Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| Lenovo ThinkPad X61s || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD slot ||<br />
|-<br />
| [[Lenovo ThinkPad X100e]] || Yes|| Yes || Yes || Yes || Yes || Yes || Not tested || NA || SD card (Yes), Webcam (Yes) ||<br />
|-<br />
| [[Lenovo ThinkPad X200]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || Yes || ||<br />
|-<br />
| [[Lenovo ThinkPad X200S]] || Yes || Yes || Yes || Yes || Yes || Not tested || NA || Not tested || Everything worked out of the box. However, fingerprint, SD card and webcam were not tested ||<br />
|-<br />
| [[Lenovo ThinkPad X201]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || ||<br />
|-<br />
| [[Lenovo ThinkPad X220]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Yes), Webcam (Yes) ||<br />
|-<br />
| [[Lenovo ThinkPad X230]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Yes), Webcam (Yes), UMTS Modem (Yes) ||<br />
|-<br />
| [[Lenovo ThinkPad X240]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || WWAN LTE (yes) || SD card (Yes), Webcam (Yes), Fingerprint (Yes) ||<br />
|-<br />
| [[Lenovo ThinkPad X250]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Yes), Webcam (Yes), Fingerprint (Yes) ||<br />
|-<br />
| [[Lenovo ThinkPad X260]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Yes), Webcam (Yes), Fingerprint (Yes) ||<br />
|-<br />
| Lenovo ThinkPad X270 || Yes || Yes || Yes || Yes || Yes || Not tested || Yes || NA || Webcam (Yes) ||<br />
|-<br />
| Lenovo ThinkPad X280 || Yes || Yes || Yes || Yes || Yes || Not tested || Yes || NA || Webcam (Yes) ||<br />
|-<br />
| [[Lenovo ThinkPad X1 Carbon]] || NA || Yes || Yes || Yes || Yes || Proprietary/nonfree || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X1 Carbon (Gen 2)]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X1 Carbon (Gen 3)]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X1 Carbon (Gen 4)]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X1 Carbon (Gen 5)]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || Yes || ||<br />
|-<br />
| [[Lenovo ThinkPad X1 Carbon (Gen 6)]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || Yes || ||<br />
|-<br />
| [[Lenovo ThinkPad X1 Extreme]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || Fingerprint reader not supported, Thunderbolt ports not tested || Graphics requires some configuration to work correctly<br />
|-<br />
| [[Lenovo ThinkPad X1 Yoga (Gen 3)]] || NA || Yes || Yes || Yes || Yes || Yes || Partial || NA || SD card (Yes), Webcam (Yes), Fingerprint (No), Touchscreen (Yes), Accelerometer (Yes) ||<br />
|}<br />
<br />
==== Yoga Series ====<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo ThinkPad Yoga 260]] || USB || Yes || Yes || Yes || Yes || Yes || Unknown || Yes || SD card (Yes), Webcam (Yes), Fingerprint Reader (Unknown), Touchscreen (Yes), Tablet (Partial), Accelerometer (No) || Wifi requires Kernel 4.3.3+<br />
|-<br />
|}<br />
<br />
==== Helix Series ====<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo ThinkPad Helix]] || Unknown || YES || YES || NA || YES || YES || NA || Touchscreen (yes), Pen (yes), Sensors (yes) || ||<br />
|-<br />
| [[Lenovo ThinkPad Helix 2nd Gen]] || 2018.04.01 (USB) || YES || YES || NA || YES || Not tested || Yes* (with updated BIOS) || Touchscreen (yes), Pen (not tested), Sensors (w/ patched kernel) || NA || Only suspend-to-idle ("freeze") is supported<br />
|-<br />
|}<br />
== Lenovo ==<br />
<br />
=== IdeaPad ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo IdeaPad 120S || 2018-04-26 || Yes || Yes || NA || Yes || Yes || Yes || NA || Everything works ||<br />
|-<br />
| [[Lenovo IdeaPad Flex 10]] || Yes || Yes* || Yes || NA || Yes || Yes || Yes || NA || Touchscreen* ||<br />
|-<br />
| [[Lenovo IdeaPad S10]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo IdeaPad S400 Touch]] || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || NA || ||<br />
|-<br />
| Lenovo IdeaPad U430p || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || NA || ||<br />
|-<br />
| Lenovo IdeaPad Y700 || 2015.12.01 || Yes || Yes* || Yes || Yes || Yes || Not tested || NA || Trackpad - [https://unix.stackexchange.com/questions/362165/lenovo-y700-elantech-touchpad-query-0x01-failed buggy] || [https://bugzilla.kernel.org/show_bug.cgi?id=151681 Trackpad requires pata_legacy to be blacklisted]<br />
|-<br />
| [[Lenovo IdeaPad Z580]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo IdeaPad 720s]] || 2018.03.01 || Yes || Yes || NA* || Yes || Yes || Yes || NA || Fingerprint reader not working || *requires USB or USB C dongle<br />
|-<br />
| [[Lenovo IdeaPad 720s (Ryzen)]] || 2018.02.01 || Not tested || Not tested || Yes* || No || Not tested || Not tested || NA || Fingerprint reader not tested but most likely not working || *requires USB or USB C dongle<br />
|-<br />
| Lenovo Ideapad 320 || 2018.03.01 || Yes || Yes || Yes || Yes || Not tested || Not tested || NA || To stop constant annoying messages by AMD-Vi, use 'iommu=soft' & 'amd_iommu=off' in kernel arguments || <br />
|-<br />
| Lenovo Ideapad N24 || 2018.04.01 || Yes || Yes || NA || Yes || Not tested || Not tested || NA || Touchscreen || <br />
|-<br />
|}<br />
<br />
=== B series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo B50 || NA || Yes || Yes || Yes || Yes || Not tested || Not tested || Not tested || ||<br />
|-<br />
| Lenovo B50-70 || Yes || Yes* ||Yes || Yes || Yes || Yes || Not tested || NA || See below* ||<br />
|-<br />
| Lenovo B450 || Yes || Yes ||Yes || Yes || Yes || NA || Not tested || NA || ||<br />
|-<br />
|}<br />
<br />
=== K series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo K450e || NA || Yes || Yes || Yes || Yes || Not tested || Yes || Not tested || ||<br />
|-<br />
|}<br />
<br />
=== N series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo N200 (3000) || Yes || Yes* || Yes || Yes || Yes || Yes* || NA || NA || See below ||<br />
|-<br />
|}<br />
<br />
=== S series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo S21e-20 || 2015.07.01 || Yes || Yes || NA || Yes* || ? || Yes || NA || SD Card (Yes), USB 3.0 (Yes), HDMI Out (?), Touchpad (Yes*) ||<br />
|-<br />
|}<br />
<br />
=== U Series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo U31-70 || 2015.10.01 || Yes || Yes || Yes || Yes* || Yes || Yes || NA || SD Card (Yes), USB 3.0 (Yes), HDMI Out (Yes), Touchpad (Yes), Webcam (Yes) ||<br />
|-<br />
|}<br />
<br />
=== V Series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo V110-15ISK || ??? || Yes || Yes || Yes || Yes || Not Tested || Yes || NA || SD Card (Not Tested), USB 3.0 (Not Tested), HDMI Out (Not Tested), Touchpad (Yes), Webcam (Yes) ||<br />
|-<br />
| Lenovo V330-15IKB || 2018.10.01 || Yes || Yes || Yes || Yes || Not Tested || Yes || NA || Fingerprint (No, no driver exists for the Validity/Synaptics 06cb:0081 Fingerprint Reader), Touchpad (Yes), Webcam (Yes) ||<br />
|-<br />
| Lenovo V330-14ARR || 2019.06.15 || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD-Card Reader (Yes) HDMI Out (Yes), USB 3.0 (Yes), Touchpad (Yes), Webcam (Yes) || DOS installable BIOS available* ||<br />
|-<br />
|}<br />
<br />
=== Y series ===<br />
{{HCL/Laptops table header}}<br />
| Lenovo Legion Y520 || 2019.06.01 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || SD card (Not working properly), Webcam (Yes), USB & USB 3.0 (Yes), HDMI (Yes), USB-C (Not tested), Touchpad (Yes), NVMe M.2 SSD (Yes), GeForce GTX 1050 Ti (Yes) || Tested June 2019 / Linux 5.1.9. Must change SATA configuration in BIOS from RAID to AHCI in order to recognize SSD.<br />
|-<br />
| Lenovo Legion Y520 || ??? || Yes || Yes || Yes || Yes || Yes || Yes || Yes || SD card (Not tested), Webcam (Yes), USB & USB 3.0 (Yes), HDMI (Yes), USB-C (Not tested), Touchpad (Yes), NVMe M.2 SSD (Yes), GeForce GTX 1050 (Yes) || Tested June 2019 / Linux 5.1.5. Must change SATA configuration in BIOS from RAID to AHCI in order to recognize SSD. Some CPU throttling is possible [https://unix.stackexchange.com/questions/491944/cpu-temperatures-in-linux-throttling-or-wrong-reading]. Fan control does not seem to work [https://unix.stackexchange.com/questions/523899/laptop-fan-always-says-its-running-at-8-rpm]<br />
|}<br />
<br />
== Special Notes (*): ==<br />
<br />
{{Accuracy|Lots of vague or unproven bugs/workarounds, poor writing}}<br />
<br />
=== Lenovo U31-70 ===<br />
Wireless needs {{Pkg|linux}} >= 4.3 and latest {{Pkg|linux-firmware}}, both packages are currently in testing. Copy one of the firmware blobs {{ic|eeprom_ar6320_2p1_NFA345i.bin}} or {{ic|eeprom_ar6320_2p1_NFA345i_highTX.bin}} from the windows driver to {{ic|/usr/lib/firmware/ath10k/QCA6174/hw2.1/board-pci-168c:0041:17aa:3545.bin}}.<br />
<br />
Wireless with firmware blobs from windows driver may no longer work on {{Pkg|linux}} >= 4.4. Download firmware blob https://github.com/kvalo/ath10k-firmware/blob/f428f53b36b144971c9c4c3d2ebd5fa8cae86c89/QCA6174/hw2.1/board-2.bin and copy it to {{ic|/usr/lib/firmware/ath10k/QCA6174/hw2.1/board-2.bin}}. Tested with {{Pkg|linux}} 4.4.5-1 and {{Pkg|linux-firmware}} 20160113.40e9ae8-1nu<br />
<br />
With packages {{Pkg|linux}} 4.6.1-2 and {{Pkg|linux-firmware}} 20160516.80d463b-1 being in stable, wireless works without any additional steps needed.<br />
<br />
=== Lenovo B50-70 ===<br />
* UEFI:<br />
** to be able to disable Secure Boot (necessary for dual boot, not needed for Linux only), you have to switch from "UEFI first" to "UEFI only" (or something like this) in UEFI setup menu; the Secure Boot option appears then on the Security tab<br />
** after UEFI update having Linux and Windows installed, the Linux bootloader ceased to be the default one, UEFI started to load Windows by default and it was impossible to select the Linux one in the UEFI boot menu and in the UEFI setup - reinstalling the bootloader helped; having no access to a boot media that supports UEFI, a solution might be also replacing the Windows EFI bootloader file with a Linux one temporalily, in order to be able to boot Linux from HDD<br />
** for the UEFI update, a Windows OS is needed<br />
* Touchpad:<br />
** Synaptics - works after installing Synaptics drivers from repo, possible to change behaviour (like reaction for double tap) according to your wish<br />
* Video:<br />
** in laptops with dual video card (Intel and ATI) - detects both, Intel is active as a default, not checked if it's possible at all to switch between them<br />
<br />
==== Operation with a HDD caddy ====<br />
When you install an SSD in the place of the plate HDD drive and you want to have your HDD still inside the laptop, it is possible to install it in the place of the optical drive in a special "HDD caddy". The optical drive is of 9 mm height, but a 9,5 mm caddy (ultra slim) fits in the slot. A caddy with a SATA interface is needed. It is difficult to separate the front bezel from the original optical drive (and opening its case does not help, but brings a danger of making a mess in the opening mechanism; the only option is just to pull the bezel using a bit of force, but you risk breaking the latches).<br />
<br />
While the HDD installed instead of the optical drive operates flawlessly in Windows, it was not going to work out of the box in Linux, at least in one case. The kernel tries to establish a connection with the disk, but fails to do it (''SATA link down'' entry in /var/log/messages). The solution is to force a 1.5 Gbps transfer speed (instead of 6 Gbps) by adding a ''libata.force='' kernel parameter. See [https://www.kernel.org/doc/Documentation/kernel-parameters.txt] for details.<br />
<br />
=== Lenovo K450e ===<br />
<br />
After installing Arch Linux and booting, a single beep may be heard. To disable this beep, press F1 during startup, then change Boot Priority to 'UEFI First', as well as enabling 'CSM'.<br />
<br />
=== ThinkPad X1 Carbon 3rd ===<br />
<br />
* http://natalian.org/archives/2015/02/18/Archlinux_on_a_Lenovo_X1C3/<br />
<br />
=== Lenovo 3000 N200 ===<br />
<br />
* Sound:<br />
** You may have to append {{ic|1=options snd_hda_intel model=lenovo}} to {{ic|/etc/modprobe.d/modprobe.conf}} for sound to work.<br />
<br />
=== Lenovo ThinkPad T430 ===<br />
{{Accuracy | I was not able to reproduce this bug as of September 2017 }}<br />
<br />
* Bluetooth (0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad]) appears to be functional, even during standby or hibernation.<br />
<br />
=== Lenovo ThinkPad T440p ===<br />
<br />
* ClickPad: the whole trackpad clicks, and disabling the trackpad using older versions of synclient makes the trackpoint essentially unusable. This has been resolved in newer versions of {{Pkg|xf86-input-synaptics}}.<br />
** See [http://who-t.blogspot.com.au/2014/03/xorg-synaptics-support-for-lenovo-t440.html this article] and [http://who-t.blogspot.com.au/2013/12/lenovo-t440-touchpad-button.html previous version].<br />
** Install {{AUR|xf86-input-mtrack}} for alternative drivers.<br />
* Audio:<br />
** HDMI audio is the default audio output device. Consult the [[ALSA]] page for details on changing the default.<br />
** As the X100e/Mini10, it's possible to mute the headset and speaker outputs separately to the master. Muting the speaker output improves bass output on the headset port.<br />
** If the system fails to wake from sleep, it can lose sync with the internal audio card and speakers/headphones may fail to work. In this case, put the system to sleep, and wake it again and audio functionality should be restored. <br />
* The fingerprint sensor is a Validity VFS5011, which requires [https://github.com/abbradar/fprint_vfs5011 a patched fprintd] and is apparently highly unreliable.<br />
* thinkpad_acpi:<br />
** To toggle Fn-Lock, press Fn + Esc, this will toggle the LED on the keyboard. While the Fn LED is on all Fn functionalities work as intended out of the box. <br />
** Controlling the 'glowing I' LED is apparently not possible.<br />
** fan control does not seem to work.<br />
* Graphics and Video:<br />
** With the integrated GPU, [[xrandr]] can crash while attaching or detaching displays connected via the dock.<br />
** The built-in miniDisplayPort will sometimes spew I²C issues into the kernel log.<br />
** [[Hardware video acceleration]] is highly recommended as it performs significantly better than CPU decoding of large media files.<br />
** '''The BIOS should not be upgraded past version 1.14, as newer BIOSes cause memory corruption when used with Bumblebee.''' See [https://github.com/Bumblebee-Project/bbswitch/issues/78#issuecomment-42741698 Bumblebee GitHub]<br />
* Connectivity:<br />
** Bluetooth is ''extremely'' fragile. The controller works fine most of the time, but can cause the system to wedge totally on sleep/wake cycles, especially if a connection was active at sleep. Disable the controller using {{ic|bluetoothctl}} before sleeping.<br />
<br />
=== Lenovo ThinkPad T560 ===<br />
* No automatic brightness adjusting when switching power supply battery <-> AC<br />
<br />
* Hardware specifications of test device<br />
** CPU: Intel CORE i7-6600U @ 2.60GHz or Intel CORE i5-6200U @ 2.30GHz or Intel CORE i5-6300U @ 2.40GHz<br />
** GPU Primary: Intel HD 520<br />
** GPU Secondary: Nvidia GeForce 940MX or None<br />
** WiFi: Intel 8260<br />
** Ethernet: Intel I219-LM<br />
** Card reader: Realtek RTS522A<br />
<br />
=== Lenovo S21e-20 ===<br />
* Tested with {{Pkg|broadcom-wl-dkms}} 802.11 wireless driver<br />
* Synaptics touchpad required 3 patches to {{Pkg|linux}}:drivers/hid/hid-rmi.c on 2015-07-26 ([https://bugs.freedesktop.org/show_bug.cgi?id=91102 bug report], [https://github.com/harisokanovic/archlinux-packages/commit/f4550c211ca7809ecf926f8074c7b7250a74bd92 kernel recipe patch]). The current 4.3 kernel includes these patches. You will also need to install the xf86_64-input-synaptics package([https://www.archlinux.org/packages/?name=xf86-input-synaptics]) <br />
<br />
==== tpacpi-bat ====<br />
<br />
There is an issue with tpacpi-bat not reporting the right value for the stop threshold. This seems to be related to a buggy BIOS and can not be fixed application wise. <br />
<br />
See https://github.com/teleshoes/tpacpi-bat/issues/44<br />
<br />
==== ThinkPad Edge E420s Delay with Space Bar====<br />
Solution: Update BIOS (at least 1.08).<br />
<br />
=== Lenovo IdeaPad Y700 ===<br />
* The subwoofer does not work out of the box.<br />
** Updating to Kernel 4.15 or later seems to fix the subwoofer.<br />
<br />
=== Lenovo IdeaPad V330-14ARR ===<br />
* Lenovo only provide BIOS updates as a WinX64 package. The 3.05 release has been extracted and can be installed in DOS using H2OFFT-D.EXE and is available [https://drive.google.com/drive/folders/1IgwALJ_LLHY1nRbl3naNJU1QQ7l33Vrv?usp=sharing online].<br />
<br />
== See also ==<br />
* [http://www.thinkwiki.org/wiki Think wiki]</div>Ritkahttps://wiki.archlinux.org/index.php?title=LightDM&diff=485843LightDM2017-08-18T18:49:26Z<p>Ritka: /* User switching */ added link to the light-locker section in the warning</p>
<hr />
<div>[[Category:Display managers]]<br />
[[es:LightDM]]<br />
[[fr:LightDM]]<br />
[[ja:LightDM]]<br />
[[ru:LightDM]]<br />
[[zh-hans:LightDM]]<br />
{{Related articles start}}<br />
{{Related|Display manager}}<br />
{{Related|GDM}}<br />
{{Related|KDM}}<br />
{{Related|LXDM}}<br />
{{Related articles end}}<br />
<br />
[http://www.freedesktop.org/wiki/Software/LightDM LightDM] is a cross-desktop [[display manager]]. Its key features are:<br />
* Cross-desktop - supports different desktop technologies.<br />
* Supports different display technologies (X, Mir, ...).<br />
* Lightweight - low memory usage and high performance.<br />
* Supports guest sessions.<br />
* Supports remote login (incoming - XDMCP, VNC, outgoing - XDMCP, pluggable).<br />
* Comprehensive test suite.<br />
* Low code complexity.<br />
<br />
More details about LightDM's design can be found [http://www.freedesktop.org/wiki/Software/LightDM/Design here].<br />
<br />
== Installation ==<br />
<br />
[[Install]] {{Pkg|lightdm}}. Note that stable releases are even-numbered (1.8, 1.10) while development releases are odd-numbered (1.9, 1.11). These development releases are available with {{AUR|lightdm-devel}}. Also available is {{AUR|lightdm-bzr}}.<br />
<br />
=== Greeter===<br />
<br />
You will probably want to install a greeter. A greeter is a GUI that prompts the user for credentials, lets the user select a session, and so on. It's possible to use LightDM without a greeter, but only if an automatic login is configured. The reference greeter is {{Pkg|lightdm-gtk-greeter}}. LightDM attempts to use this greeter when started unless configured to do otherwise.<br />
<br />
The official repositories contain the following alternative greeters.<br />
* {{Pkg|lightdm-kde-greeter}}: A greeter used with KDE4.<br />
* lightdm-deepin-greeter ({{Pkg|deepin-session-ui}}): A greeter from the [[Deepin]] project.<br />
<br />
Other alternative greeters are available in the [[AUR]].<br />
* {{AUR|lightdm-webkit2-greeter}}: A greeter that uses Webkit2 for theming. It supersedes {{AUR|lightdm-webkit-greeter}}.<br />
* {{AUR|lightdm-unity-greeter}}: The greeter used by Ubuntu's [[Unity]].<br />
* {{AUR|lightdm-pantheon-greeter}}: A greeter from the elementary OS project.<br />
* {{AUR|lightdm-mini-greeter}}: A minimal, configurable, single-user greeter.<br />
<br />
You can set the default greeter by changing the {{ic|[Seat:*]}} section of the LightDM configuration file, like so:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
...<br />
greeter-session=lightdm-yourgreeter-greeter<br />
}}<br />
<br />
Which greeters are available? What values may be assigned to the {{ic|greeter-session}} option? Each {{ic|.desktop}} file in the {{ic|/usr/share/xgreeters}} directory denotes an available greeter. In this example, the {{ic|lightdm-gtk-greeter}} and {{ic|lightdm-kde-greeter}} greeters are available:<br />
$ ls -1 /usr/share/xgreeters/<br />
lightdm-gtk-greeter.desktop<br />
lightdm-kde-greeter.desktop<br />
<br />
== Enabling LightDM ==<br />
<br />
Make sure to [[enable]] {{ic|lightdm.service}} so LightDM will be started at boot, see also [[Display manager#Loading the display manager]].<br />
<br />
== Command line tool ==<br />
<br />
LightDM offers a command line tool, {{ic|dm-tool}}, which can be used to lock the current seat, switch sessions, etc, which is useful with 'minimalist' window managers and for testing. To see a list of available commands, execute:<br />
$ dm-tool --help<br />
<br />
=== User switching ===<br />
<br />
{{Warning|1=The use of lightDM's built-in screen lockers like {{ic|dm-tool lock}} or {{ic|dm-tool switch-to-greeter}} [https://bbs.archlinux.org/viewtopic.php?pid=1712213#p1712213 are '''not''' recommended]. Use [[LightDM#Lock_the_screen_using_light-locker|light-locker]] or something from [[List of applications/Security#Screen lockers]].}}<br />
<br />
LightDM's ''dm-tool'' command can be used to allow multiple users to be logged in on separate ttys. The following will send a signal requesting that the current session be locked and then will initiate a switch to LightDM's greeter, allowing a new user to log in to the system.<br />
<br />
$ dm-tool switch-to-greeter<br />
<br />
== Testing ==<br />
<br />
First, [[install]] {{Pkg|xorg-server-xephyr}} from the [[official repositories]].<br />
<br />
Then, run LightDM as an X application:<br />
$ lightdm --test-mode --debug<br />
<br />
== Optional configuration and tweaks ==<br />
<br />
LightDM can be configured by modifying its config file, {{ic|/etc/lightdm/lightdm.conf}}.<br />
<br />
Some greeters have their own configuration files. For example:<br />
<br />
{{Pkg|lightdm-gtk-greeter}}: {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}}<br />
<br />
{{AUR|lightdm-webkit2-greeter}}: {{ic|/etc/lightdm/lightdm-webkit2-greeter.conf}}<br />
<br />
{{Pkg|lightdm-kde-greeter}}: {{ic|/etc/lightdm/lightdm-kde-greeter.conf}}<br />
<br />
=== Changing background images/colors ===<br />
<br />
You can set the background to a hex color or an image. Some greeters offer more robust background options like background selection from the login screen, random backgrounds, etc.<br />
<br />
==== GTK+ greeter ====<br />
<br />
You can use the {{Pkg|lightdm-gtk-greeter-settings}} gui.<br />
<br />
Users wishing to customize the wallpaper on the greeter screen need to edit {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} and define the {{ic|background}} variable under the {{ic|[greeter]}} section. For example:<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
background=/usr/share/pixmaps/black_and_white_photography-wallpaper-1920x1080.jpg<br />
}}<br />
<br />
{{Note|It is recommended to place the PNG or JPG file in {{ic|/usr/share/pixmaps}} since the LightDM user needs read access to the wallpaper file.}}<br />
<br />
===== GTK3 Dark Theme =====<br />
GTK3 introduced "dark" alternate color palettes for themes, but lightdm-gtk-greeter does not yet support specifing one natively. A workaround is to override the theme with an evironment variable in {{ic|/usr/share/xgreeters/lightdm-gtk-greeter.desktop}} For example:<br />
{{hc|/usr/share/xgreeters/lightdm-gtk-greeter.desktop|2=<br />
[Desktop Entry]<br />
Name=LightDM GTK+ Greeter<br />
Comment=This runs the GTK+ greeter, it should only be run from LightDM<br />
Exec=env GTK_THEME=Adwaita:dark lightdm-gtk-greeter<br />
Type=Application<br />
X-Ubuntu-Gettext-Domain=lightdm<br />
}}<br />
<br />
==== Webkit2 greeter ====<br />
<br />
The {{AUR|lightdm-webkit2-greeter}} allows you to choose a background image directly on the login screen. It also offers an option to display a random image each time it starts. By default, images are sourced from {{ic|/usr/share/backgrounds}}. You can change the background images directory by editing {{ic|lightdm-webkit2-greeter.conf}}. For example:<br />
{{hc|/etc/lightdm/lightdm-webkit2-greeter.conf|2=<br />
[branding]<br />
background_images = /usr/share/backgrounds<br />
}}<br />
<br />
{{Note|The background images directory must be accessible to the LightDM user so it should not be located anywhere under {{ic|/home}}. }}<br />
<br />
==== Unity greeter ====<br />
<br />
Users using the {{AUR|lightdm-unity-greeter}} must edit the {{ic|/usr/share/glib-2.0/schemas/com.canonical.unity-greeter.gschema.xml}} file and then execute:<br />
# glib-compile-schemas /usr/share/glib-2.0/schemas/<br />
<br />
According to [https://bbs.archlinux.org/viewtopic.php?id=149945 this] page.<br />
<br />
==== KDE greeter ====<br />
<br />
Go to ''System Settings > Login Screen (LightDM)'' and change the background image for your theme.<br />
<br />
Alternatively, you can edit the {{ic|Background}} variable in {{ic|lightdm-kde-greeter.conf}} :<br />
<br />
{{hc|/etc/lightdm/lightdm-kde-greeter.conf|2=<br />
[greeter]<br />
theme-name=classic<br />
<br />
[greeter-settings]<br />
Background=/usr/share/archlinux/wallpaper/archlinux-underground.jpg<br />
BackgroundKeepAspectRatio=true<br />
GreetMessage=Welcome to %hostname%<br />
}}<br />
<br />
=== Changing your avatar ===<br />
<br />
{{Tip|If you are using KDE, you can change your avatar in KDE System Settings.}}<br />
<br />
First, make sure the {{pkg|accountsservice}} package from the [[official repositories]] is installed, then set it up as follows, replacing {{ic|''username''}} with the desired user's login name. The ''.png'' file extension should not be included in the filename.<br />
<br />
* Edit or create the file {{ic|/var/lib/AccountsService/users/''username''}}, and add the lines<br />
<br />
[User]<br />
Icon=/var/lib/AccountsService/icons/''username''<br />
<br />
* Create the file {{ic|/var/lib/AccountsService/icons/''username''}} using a 96x96 PNG image file.<br />
<br />
{{Note|Make sure that both created files have 644 permissions, use [[chmod]] to correct them.}}<br />
<br />
=== Sources of Arch-centric 64x64 icons ===<br />
<br />
The {{AUR|archlinux-artwork}} package from the [[AUR]] contains some nice examples that install to {{ic|/usr/share/archlinux/icons}} and that can be copied to {{ic|/usr/share/icons/hicolor/64x64/devices}} as follows:<br />
<br />
# find /usr/share/archlinux/icons -name "*64*" -exec cp {} /usr/share/icons/hicolor/64x64/devices \;<br />
<br />
After copying, the {{AUR|archlinux-artwork}} package can be removed.<br />
<br />
=== Enabling autologin ===<br />
<br />
Edit the LightDM configuration file and ensure these lines are uncommented and correctly configured:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
autologin-user=''username''<br />
}}<br />
<br />
You must be part of the {{ic|autologin}} group to be able to login automatically without entering your password:<br />
<br />
# groupadd -r autologin<br />
# gpasswd -a ''username'' autologin<br />
<br />
LightDM logs in using the session specified in the {{ic|~/.dmrc}} of the user getting logged in automatically. To override this file, specify {{ic|autologin-session}} in {{ic|lightdm.conf}}:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
autologin-user=''username''<br />
autologin-session=''session''<br />
}}<br />
<br />
{{Note|GNOME users, and by extension any gnome-keyring user will have to set up a blank password to their keyring for it to be unlocked automatically.}}<br />
<br />
=== Enabling interactive passwordless login ===<br />
<br />
LightDM goes through PAM so you must configure the lightdm configuration of PAM:<br />
<br />
{{hc|/etc/pam.d/lightdm|2=<br />
#%PAM-1.0<br />
'''auth sufficient pam_succeed_if.so user ingroup nopasswdlogin'''<br />
auth include system-login<br />
...<br />
}}<br />
<br />
You must then also be part of the {{ic|nopasswdlogin}} group to be able to login interactively without entering your password:<br />
<br />
# groupadd -r nopasswdlogin<br />
# gpasswd -a ''username'' nopasswdlogin<br />
<br />
{{Note|GNOME users, and by extension any gnome-keyring user may have to follow the instructions at the end of the previous section on enabling autologin.}}<br />
<br />
To create a new user account that logs in automatically and additionally able to login again without a password the user can be created with supplementary membership of both groups, e.g.:<br />
<br />
# useradd -mG autologin,nopasswdlogin -s /bin/bash ''username''<br />
<br />
=== Hiding system and services users ===<br />
To prevent system users from showing-up in the login, install the optional dependency {{Pkg|accountsservice}}, or add the user names to {{ic|/etc/lightdm/users.conf}} under {{ic|hidden-users}}. The first option has the advantage of not needing to update the list when more users are added or removed.<br />
<br />
=== Migrating from SLiM ===<br />
<br />
Move the contents of [[xinitrc]] to [[xprofile]], removing the call to start the [[window manager]] or [[desktop environment]].<br />
<br />
=== Login using ~/.xinitrc ===<br />
<br />
Although migrating to an [[xprofile]] is the preferred method of using a custom start script, it is possible to use your [[xinitrc]] by installing {{AUR|xinit-xsession}}. This provides the necessary file in {{ic|/usr/share/xsessions/}}, so the option will become available on a restart of lightdm.<br />
<br />
=== NumLock on by default ===<br />
<br />
Install the {{Pkg|numlockx}} package and then edit {{ic|/etc/lightdm/lightdm.conf}}:<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
greeter-setup-script=/usr/bin/numlockx on<br />
}}<br />
<br />
=== Default session ===<br />
<br />
Lightdm, like other DMs, stores the last-selected xsession in {{ic|~/.dmrc}}. See [[Display manager#Session configuration]] for more info.<br />
<br />
=== Adjusting the login window's position ===<br />
<br />
==== GTK+ greeter ====<br />
<br />
Users need to edit {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} and enter a value for the {{ic|position}} variable. It accepts {{ic|x}} and {{ic|y}} values, either absolute (in pixels) or relative (in percent). Each value can also have an additional anchor location for the window, {{ic|start}}, {{ic|center}} and {{ic|end}} separated from the value by a comma.<br />
<br />
Example:<br />
<br />
position=200,start 50%,center<br />
<br />
=== VNC Server ===<br />
Lightdm can also be used to connect to via VNC. Make sure to install {{pkg|tigervnc}} on the server side and optionally as your VNC client on the client PC.<br />
<br />
Setup an authentication password on the server as root:<br />
<br />
# vncpasswd /etc/vncpasswd<br />
<br />
Edit the LightDM configuration file as shown below. Note that {{ic|listen-address}} configures the VNC to only listen to connections from localhost. This is used to only allow connections via [[TigerVNC#On_the_client|SSH and port forwarding]]. On the SSH client, make sure that you use {{ic|localhost:5900}} for the tunnel destination; using {{ic|127.0.0.1:5900}} or {{ic|::1:5900}} is not reliable on dual stack network connections. If you want to allow insecure connections you can disable this setting.<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[VNCServer]<br />
enabled=true<br />
command=Xvnc -rfbauth /etc/vncpasswd<br />
port=5900<br />
listen-address=localhost<br />
width=1024<br />
height=768<br />
depth=24<br />
}}<br />
<br />
Now open an SSH tunnel and connect to localhost as described in [[TigerVNC#On the client]].<br />
<br />
{{Note|If you get a blank screen upon opening the VNC connection, try a different LightDM greeter.}}<br />
<br />
=== Lock the screen using light-locker ===<br />
{{Pkg|light-locker}} is a simple screen locker using LightDM to authenticate the user. Once it is installed and running you can lock your session using<br />
$ light-locker-command -l<br />
This requires {{ic|light-locker}} to be started at the beginning of your session. Therefore the file {{ic|/etc/xdg/autostart/light-locker.desktop}} is created during the installation. This file is loaded automatically by any XDG-compliant desktop environment (see [[Desktop_entries#Autostart]]). However, if you are just using a window manager, usually this file will not be loaded automatically. In this case you simply have to add {{ic|light-locker}} to your {{ic|.xprofile}} file:<br />
{{hc|.xprofile|<br />
...<br />
light-locker &<br />
...<br />
}}<br />
<br />
== Troubleshooting ==<br />
If you encounter consistent screen flashing and ultimately no LightDM on boot, ensure that you have defined the greeter correctly in LightDM's config file. And if you have correctly defined the GTK greeter, make sure the {{ic|xsessions-directory}} (default: {{ic|/usr/share/xsessions}}) exists and contains at least one .desktop file.<br />
<br />
The same error can happen on lightdm startup if the last used session is not available anymore (eg. you last used gnome and then removed the gnome-session package): the easiest workaround is to temporarily restore the removed package. Another solution might be:<br />
<br />
# dbus-send --system --type=method_call --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts/User1000 org.freedesktop.Accounts.User.SetXSession string:xfce<br />
<br />
This example sets the session "xfce" as default for the user 1000.<br />
<br />
=== Wrong locale displayed ===<br />
<br />
In case of your locale not being displayed correctly in Lightdm add your locale to {{ic|/etc/environment}}<br />
LANG=pt_PT.utf8<br />
<br />
Alternatively if you want LightDM and its greeters to be in a language other than your set system locale, you can use the {{ic|1=Environment=}} option in [[Systemd#Drop-in files]].<br />
<br />
=== Missing icons with GTK greeter ===<br />
<br />
If you are using {{Pkg|lightdm-gtk-greeter}} as a greeter and it shows placeholder images as icons, make sure valid icon themes and themes are installed and configured. Check the following file:<br />
<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
theme-name=mate # this should be the name of a directory under /usr/share/themes/<br />
icon-theme-name=mate # this should be the name of a fully featured icons set directory under /usr/share/icons/<br />
}}<br />
<br />
=== LightDM freezes on login attempt ===<br />
<br />
You may find that after entering the correct username and password and attempting to log in, LightDM freezes and you are unable to continue to the desktop. To fix the issue, reinstall the {{Pkg|gdk-pixbuf2}} package. See [https://bbs.archlinux.org/viewtopic.php?id=179031 this forum thread].<br />
<br />
=== LightDM displaying in wrong monitor ===<br />
<br />
If you are using multiple monitors, LightDM may display in the wrong one (e.g. if your primary monitor is on the right). To force the LightDM login screen to display on a specific monitor, edit {{ic|/etc/lightdm/lightdm.conf}} and change the ''display-setup-script'' parameter like this:<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
display-setup-script=xrandr --output ''HDMI1'' --primary<br />
}}<br />
<br />
Replace ''HDMI1'' with your real monitor ID, which you can find from '''xrandr''' command output.<br />
<br />
Alternatively, if you are using the GTK+ greeter, you can edit {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} and add the ''active-monitor'' parameter like this:<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
active-monitor=0<br />
}}<br />
<br />
Replace 0 with the desired display number.<br />
<br />
=== LightDM does not appear ===<br />
<br />
It may happen that your system boots so fast that LightDM service is started before your graphics drivers are properly loaded. If this is your case, you will want to add the following config to your lightdm.conf file:<br />
<br />
[LightDM]<br />
logind-check-graphical=true<br />
<br />
This setting will tell LightDM to wait until graphics devices are ready before spawning greeters/autostarting sessions on them.<br />
<br />
=== Pulseaudio not starting automatically ===<br />
<br />
See [[PulseAudio#Running]].<br />
<br />
== See also ==<br />
<br />
* {{Pkg|light-locker}}, a screen locker using LightDM.<br />
* [https://wiki.ubuntu.com/LightDM Ubuntu Wiki article]<br />
* [http://wiki.gentoo.org/wiki/LightDM Gentoo Wiki article]<br />
* [https://launchpad.net/lightdm Launchpad Page]<br />
* [http://www.mattfischer.com/blog/?tag=lightdm LightDM blog]</div>Ritkahttps://wiki.archlinux.org/index.php?title=LightDM&diff=485842LightDM2017-08-18T18:38:25Z<p>Ritka: added section about light-locker with a hint on how to enable it for non-XDG-compliant WMs</p>
<hr />
<div>[[Category:Display managers]]<br />
[[es:LightDM]]<br />
[[fr:LightDM]]<br />
[[ja:LightDM]]<br />
[[ru:LightDM]]<br />
[[zh-hans:LightDM]]<br />
{{Related articles start}}<br />
{{Related|Display manager}}<br />
{{Related|GDM}}<br />
{{Related|KDM}}<br />
{{Related|LXDM}}<br />
{{Related articles end}}<br />
<br />
[http://www.freedesktop.org/wiki/Software/LightDM LightDM] is a cross-desktop [[display manager]]. Its key features are:<br />
* Cross-desktop - supports different desktop technologies.<br />
* Supports different display technologies (X, Mir, ...).<br />
* Lightweight - low memory usage and high performance.<br />
* Supports guest sessions.<br />
* Supports remote login (incoming - XDMCP, VNC, outgoing - XDMCP, pluggable).<br />
* Comprehensive test suite.<br />
* Low code complexity.<br />
<br />
More details about LightDM's design can be found [http://www.freedesktop.org/wiki/Software/LightDM/Design here].<br />
<br />
== Installation ==<br />
<br />
[[Install]] {{Pkg|lightdm}}. Note that stable releases are even-numbered (1.8, 1.10) while development releases are odd-numbered (1.9, 1.11). These development releases are available with {{AUR|lightdm-devel}}. Also available is {{AUR|lightdm-bzr}}.<br />
<br />
=== Greeter===<br />
<br />
You will probably want to install a greeter. A greeter is a GUI that prompts the user for credentials, lets the user select a session, and so on. It's possible to use LightDM without a greeter, but only if an automatic login is configured. The reference greeter is {{Pkg|lightdm-gtk-greeter}}. LightDM attempts to use this greeter when started unless configured to do otherwise.<br />
<br />
The official repositories contain the following alternative greeters.<br />
* {{Pkg|lightdm-kde-greeter}}: A greeter used with KDE4.<br />
* lightdm-deepin-greeter ({{Pkg|deepin-session-ui}}): A greeter from the [[Deepin]] project.<br />
<br />
Other alternative greeters are available in the [[AUR]].<br />
* {{AUR|lightdm-webkit2-greeter}}: A greeter that uses Webkit2 for theming. It supersedes {{AUR|lightdm-webkit-greeter}}.<br />
* {{AUR|lightdm-unity-greeter}}: The greeter used by Ubuntu's [[Unity]].<br />
* {{AUR|lightdm-pantheon-greeter}}: A greeter from the elementary OS project.<br />
* {{AUR|lightdm-mini-greeter}}: A minimal, configurable, single-user greeter.<br />
<br />
You can set the default greeter by changing the {{ic|[Seat:*]}} section of the LightDM configuration file, like so:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
...<br />
greeter-session=lightdm-yourgreeter-greeter<br />
}}<br />
<br />
Which greeters are available? What values may be assigned to the {{ic|greeter-session}} option? Each {{ic|.desktop}} file in the {{ic|/usr/share/xgreeters}} directory denotes an available greeter. In this example, the {{ic|lightdm-gtk-greeter}} and {{ic|lightdm-kde-greeter}} greeters are available:<br />
$ ls -1 /usr/share/xgreeters/<br />
lightdm-gtk-greeter.desktop<br />
lightdm-kde-greeter.desktop<br />
<br />
== Enabling LightDM ==<br />
<br />
Make sure to [[enable]] {{ic|lightdm.service}} so LightDM will be started at boot, see also [[Display manager#Loading the display manager]].<br />
<br />
== Command line tool ==<br />
<br />
LightDM offers a command line tool, {{ic|dm-tool}}, which can be used to lock the current seat, switch sessions, etc, which is useful with 'minimalist' window managers and for testing. To see a list of available commands, execute:<br />
$ dm-tool --help<br />
<br />
=== User switching ===<br />
<br />
{{Warning|1=The use of lightDM's built-in screen lockers like {{ic|dm-tool lock}} or {{ic|dm-tool switch-to-greeter}} [https://bbs.archlinux.org/viewtopic.php?pid=1712213#p1712213 are '''not''' recommended]. Use something else, e.g. from [[List of applications/Security#Screen lockers]].}}<br />
<br />
LightDM's ''dm-tool'' command can be used to allow multiple users to be logged in on separate ttys. The following will send a signal requesting that the current session be locked and then will initiate a switch to LightDM's greeter, allowing a new user to log in to the system.<br />
<br />
$ dm-tool switch-to-greeter<br />
<br />
== Testing ==<br />
<br />
First, [[install]] {{Pkg|xorg-server-xephyr}} from the [[official repositories]].<br />
<br />
Then, run LightDM as an X application:<br />
$ lightdm --test-mode --debug<br />
<br />
== Optional configuration and tweaks ==<br />
<br />
LightDM can be configured by modifying its config file, {{ic|/etc/lightdm/lightdm.conf}}.<br />
<br />
Some greeters have their own configuration files. For example:<br />
<br />
{{Pkg|lightdm-gtk-greeter}}: {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}}<br />
<br />
{{AUR|lightdm-webkit2-greeter}}: {{ic|/etc/lightdm/lightdm-webkit2-greeter.conf}}<br />
<br />
{{Pkg|lightdm-kde-greeter}}: {{ic|/etc/lightdm/lightdm-kde-greeter.conf}}<br />
<br />
=== Changing background images/colors ===<br />
<br />
You can set the background to a hex color or an image. Some greeters offer more robust background options like background selection from the login screen, random backgrounds, etc.<br />
<br />
==== GTK+ greeter ====<br />
<br />
You can use the {{Pkg|lightdm-gtk-greeter-settings}} gui.<br />
<br />
Users wishing to customize the wallpaper on the greeter screen need to edit {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} and define the {{ic|background}} variable under the {{ic|[greeter]}} section. For example:<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
background=/usr/share/pixmaps/black_and_white_photography-wallpaper-1920x1080.jpg<br />
}}<br />
<br />
{{Note|It is recommended to place the PNG or JPG file in {{ic|/usr/share/pixmaps}} since the LightDM user needs read access to the wallpaper file.}}<br />
<br />
===== GTK3 Dark Theme =====<br />
GTK3 introduced "dark" alternate color palettes for themes, but lightdm-gtk-greeter does not yet support specifing one natively. A workaround is to override the theme with an evironment variable in {{ic|/usr/share/xgreeters/lightdm-gtk-greeter.desktop}} For example:<br />
{{hc|/usr/share/xgreeters/lightdm-gtk-greeter.desktop|2=<br />
[Desktop Entry]<br />
Name=LightDM GTK+ Greeter<br />
Comment=This runs the GTK+ greeter, it should only be run from LightDM<br />
Exec=env GTK_THEME=Adwaita:dark lightdm-gtk-greeter<br />
Type=Application<br />
X-Ubuntu-Gettext-Domain=lightdm<br />
}}<br />
<br />
==== Webkit2 greeter ====<br />
<br />
The {{AUR|lightdm-webkit2-greeter}} allows you to choose a background image directly on the login screen. It also offers an option to display a random image each time it starts. By default, images are sourced from {{ic|/usr/share/backgrounds}}. You can change the background images directory by editing {{ic|lightdm-webkit2-greeter.conf}}. For example:<br />
{{hc|/etc/lightdm/lightdm-webkit2-greeter.conf|2=<br />
[branding]<br />
background_images = /usr/share/backgrounds<br />
}}<br />
<br />
{{Note|The background images directory must be accessible to the LightDM user so it should not be located anywhere under {{ic|/home}}. }}<br />
<br />
==== Unity greeter ====<br />
<br />
Users using the {{AUR|lightdm-unity-greeter}} must edit the {{ic|/usr/share/glib-2.0/schemas/com.canonical.unity-greeter.gschema.xml}} file and then execute:<br />
# glib-compile-schemas /usr/share/glib-2.0/schemas/<br />
<br />
According to [https://bbs.archlinux.org/viewtopic.php?id=149945 this] page.<br />
<br />
==== KDE greeter ====<br />
<br />
Go to ''System Settings > Login Screen (LightDM)'' and change the background image for your theme.<br />
<br />
Alternatively, you can edit the {{ic|Background}} variable in {{ic|lightdm-kde-greeter.conf}} :<br />
<br />
{{hc|/etc/lightdm/lightdm-kde-greeter.conf|2=<br />
[greeter]<br />
theme-name=classic<br />
<br />
[greeter-settings]<br />
Background=/usr/share/archlinux/wallpaper/archlinux-underground.jpg<br />
BackgroundKeepAspectRatio=true<br />
GreetMessage=Welcome to %hostname%<br />
}}<br />
<br />
=== Changing your avatar ===<br />
<br />
{{Tip|If you are using KDE, you can change your avatar in KDE System Settings.}}<br />
<br />
First, make sure the {{pkg|accountsservice}} package from the [[official repositories]] is installed, then set it up as follows, replacing {{ic|''username''}} with the desired user's login name. The ''.png'' file extension should not be included in the filename.<br />
<br />
* Edit or create the file {{ic|/var/lib/AccountsService/users/''username''}}, and add the lines<br />
<br />
[User]<br />
Icon=/var/lib/AccountsService/icons/''username''<br />
<br />
* Create the file {{ic|/var/lib/AccountsService/icons/''username''}} using a 96x96 PNG image file.<br />
<br />
{{Note|Make sure that both created files have 644 permissions, use [[chmod]] to correct them.}}<br />
<br />
=== Sources of Arch-centric 64x64 icons ===<br />
<br />
The {{AUR|archlinux-artwork}} package from the [[AUR]] contains some nice examples that install to {{ic|/usr/share/archlinux/icons}} and that can be copied to {{ic|/usr/share/icons/hicolor/64x64/devices}} as follows:<br />
<br />
# find /usr/share/archlinux/icons -name "*64*" -exec cp {} /usr/share/icons/hicolor/64x64/devices \;<br />
<br />
After copying, the {{AUR|archlinux-artwork}} package can be removed.<br />
<br />
=== Enabling autologin ===<br />
<br />
Edit the LightDM configuration file and ensure these lines are uncommented and correctly configured:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
autologin-user=''username''<br />
}}<br />
<br />
You must be part of the {{ic|autologin}} group to be able to login automatically without entering your password:<br />
<br />
# groupadd -r autologin<br />
# gpasswd -a ''username'' autologin<br />
<br />
LightDM logs in using the session specified in the {{ic|~/.dmrc}} of the user getting logged in automatically. To override this file, specify {{ic|autologin-session}} in {{ic|lightdm.conf}}:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
autologin-user=''username''<br />
autologin-session=''session''<br />
}}<br />
<br />
{{Note|GNOME users, and by extension any gnome-keyring user will have to set up a blank password to their keyring for it to be unlocked automatically.}}<br />
<br />
=== Enabling interactive passwordless login ===<br />
<br />
LightDM goes through PAM so you must configure the lightdm configuration of PAM:<br />
<br />
{{hc|/etc/pam.d/lightdm|2=<br />
#%PAM-1.0<br />
'''auth sufficient pam_succeed_if.so user ingroup nopasswdlogin'''<br />
auth include system-login<br />
...<br />
}}<br />
<br />
You must then also be part of the {{ic|nopasswdlogin}} group to be able to login interactively without entering your password:<br />
<br />
# groupadd -r nopasswdlogin<br />
# gpasswd -a ''username'' nopasswdlogin<br />
<br />
{{Note|GNOME users, and by extension any gnome-keyring user may have to follow the instructions at the end of the previous section on enabling autologin.}}<br />
<br />
To create a new user account that logs in automatically and additionally able to login again without a password the user can be created with supplementary membership of both groups, e.g.:<br />
<br />
# useradd -mG autologin,nopasswdlogin -s /bin/bash ''username''<br />
<br />
=== Hiding system and services users ===<br />
To prevent system users from showing-up in the login, install the optional dependency {{Pkg|accountsservice}}, or add the user names to {{ic|/etc/lightdm/users.conf}} under {{ic|hidden-users}}. The first option has the advantage of not needing to update the list when more users are added or removed.<br />
<br />
=== Migrating from SLiM ===<br />
<br />
Move the contents of [[xinitrc]] to [[xprofile]], removing the call to start the [[window manager]] or [[desktop environment]].<br />
<br />
=== Login using ~/.xinitrc ===<br />
<br />
Although migrating to an [[xprofile]] is the preferred method of using a custom start script, it is possible to use your [[xinitrc]] by installing {{AUR|xinit-xsession}}. This provides the necessary file in {{ic|/usr/share/xsessions/}}, so the option will become available on a restart of lightdm.<br />
<br />
=== NumLock on by default ===<br />
<br />
Install the {{Pkg|numlockx}} package and then edit {{ic|/etc/lightdm/lightdm.conf}}:<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
greeter-setup-script=/usr/bin/numlockx on<br />
}}<br />
<br />
=== Default session ===<br />
<br />
Lightdm, like other DMs, stores the last-selected xsession in {{ic|~/.dmrc}}. See [[Display manager#Session configuration]] for more info.<br />
<br />
=== Adjusting the login window's position ===<br />
<br />
==== GTK+ greeter ====<br />
<br />
Users need to edit {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} and enter a value for the {{ic|position}} variable. It accepts {{ic|x}} and {{ic|y}} values, either absolute (in pixels) or relative (in percent). Each value can also have an additional anchor location for the window, {{ic|start}}, {{ic|center}} and {{ic|end}} separated from the value by a comma.<br />
<br />
Example:<br />
<br />
position=200,start 50%,center<br />
<br />
=== VNC Server ===<br />
Lightdm can also be used to connect to via VNC. Make sure to install {{pkg|tigervnc}} on the server side and optionally as your VNC client on the client PC.<br />
<br />
Setup an authentication password on the server as root:<br />
<br />
# vncpasswd /etc/vncpasswd<br />
<br />
Edit the LightDM configuration file as shown below. Note that {{ic|listen-address}} configures the VNC to only listen to connections from localhost. This is used to only allow connections via [[TigerVNC#On_the_client|SSH and port forwarding]]. On the SSH client, make sure that you use {{ic|localhost:5900}} for the tunnel destination; using {{ic|127.0.0.1:5900}} or {{ic|::1:5900}} is not reliable on dual stack network connections. If you want to allow insecure connections you can disable this setting.<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[VNCServer]<br />
enabled=true<br />
command=Xvnc -rfbauth /etc/vncpasswd<br />
port=5900<br />
listen-address=localhost<br />
width=1024<br />
height=768<br />
depth=24<br />
}}<br />
<br />
Now open an SSH tunnel and connect to localhost as described in [[TigerVNC#On the client]].<br />
<br />
{{Note|If you get a blank screen upon opening the VNC connection, try a different LightDM greeter.}}<br />
<br />
=== Lock the screen using light-locker ===<br />
{{Pkg|light-locker}} is a simple screen locker using LightDM to authenticate the user. Once it is installed and running you can lock your session using<br />
$ light-locker-command -l<br />
This requires {{ic|light-locker}} to be started at the beginning of your session. Therefore the file {{ic|/etc/xdg/autostart/light-locker.desktop}} is created during the installation. This file is loaded automatically by any XDG-compliant desktop environment (see [[Desktop_entries#Autostart]]). However, if you are just using a window manager, usually this file will not be loaded automatically. In this case you simply have to add {{ic|light-locker}} to your {{ic|.xprofile}} file:<br />
{{hc|.xprofile|<br />
...<br />
light-locker &<br />
...<br />
}}<br />
<br />
== Troubleshooting ==<br />
If you encounter consistent screen flashing and ultimately no LightDM on boot, ensure that you have defined the greeter correctly in LightDM's config file. And if you have correctly defined the GTK greeter, make sure the {{ic|xsessions-directory}} (default: {{ic|/usr/share/xsessions}}) exists and contains at least one .desktop file.<br />
<br />
The same error can happen on lightdm startup if the last used session is not available anymore (eg. you last used gnome and then removed the gnome-session package): the easiest workaround is to temporarily restore the removed package. Another solution might be:<br />
<br />
# dbus-send --system --type=method_call --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts/User1000 org.freedesktop.Accounts.User.SetXSession string:xfce<br />
<br />
This example sets the session "xfce" as default for the user 1000.<br />
<br />
=== Wrong locale displayed ===<br />
<br />
In case of your locale not being displayed correctly in Lightdm add your locale to {{ic|/etc/environment}}<br />
LANG=pt_PT.utf8<br />
<br />
Alternatively if you want LightDM and its greeters to be in a language other than your set system locale, you can use the {{ic|1=Environment=}} option in [[Systemd#Drop-in files]].<br />
<br />
=== Missing icons with GTK greeter ===<br />
<br />
If you are using {{Pkg|lightdm-gtk-greeter}} as a greeter and it shows placeholder images as icons, make sure valid icon themes and themes are installed and configured. Check the following file:<br />
<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
theme-name=mate # this should be the name of a directory under /usr/share/themes/<br />
icon-theme-name=mate # this should be the name of a fully featured icons set directory under /usr/share/icons/<br />
}}<br />
<br />
=== LightDM freezes on login attempt ===<br />
<br />
You may find that after entering the correct username and password and attempting to log in, LightDM freezes and you are unable to continue to the desktop. To fix the issue, reinstall the {{Pkg|gdk-pixbuf2}} package. See [https://bbs.archlinux.org/viewtopic.php?id=179031 this forum thread].<br />
<br />
=== LightDM displaying in wrong monitor ===<br />
<br />
If you are using multiple monitors, LightDM may display in the wrong one (e.g. if your primary monitor is on the right). To force the LightDM login screen to display on a specific monitor, edit {{ic|/etc/lightdm/lightdm.conf}} and change the ''display-setup-script'' parameter like this:<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
display-setup-script=xrandr --output ''HDMI1'' --primary<br />
}}<br />
<br />
Replace ''HDMI1'' with your real monitor ID, which you can find from '''xrandr''' command output.<br />
<br />
Alternatively, if you are using the GTK+ greeter, you can edit {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} and add the ''active-monitor'' parameter like this:<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
active-monitor=0<br />
}}<br />
<br />
Replace 0 with the desired display number.<br />
<br />
=== LightDM does not appear ===<br />
<br />
It may happen that your system boots so fast that LightDM service is started before your graphics drivers are properly loaded. If this is your case, you will want to add the following config to your lightdm.conf file:<br />
<br />
[LightDM]<br />
logind-check-graphical=true<br />
<br />
This setting will tell LightDM to wait until graphics devices are ready before spawning greeters/autostarting sessions on them.<br />
<br />
=== Pulseaudio not starting automatically ===<br />
<br />
See [[PulseAudio#Running]].<br />
<br />
== See also ==<br />
<br />
* {{Pkg|light-locker}}, a screen locker using LightDM.<br />
* [https://wiki.ubuntu.com/LightDM Ubuntu Wiki article]<br />
* [http://wiki.gentoo.org/wiki/LightDM Gentoo Wiki article]<br />
* [https://launchpad.net/lightdm Launchpad Page]<br />
* [http://www.mattfischer.com/blog/?tag=lightdm LightDM blog]</div>Ritkahttps://wiki.archlinux.org/index.php?title=Display_manager&diff=485292Display manager2017-08-13T18:10:56Z<p>Ritka: /* Session configuration */ Removed Encoding field in Desktop Entries, because it's deprecated. Changed/Added Type in Desktop Entries to Application (there is no such type as XSession). checked with desktop-file-validate.</p>
<hr />
<div>[[Category:Display managers]]<br />
[[ar:Display manager]]<br />
[[cs:Display manager]]<br />
[[de:Login-Manager]]<br />
[[es:Display manager]]<br />
[[fa:Display manager]]<br />
[[fr:Gestionnaire de connexions]]<br />
[[he:Display manager]]<br />
[[it:Display manager]]<br />
[[ja:ディスプレイマネージャ]]<br />
[[pt:Display manager]]<br />
[[ru:Display manager]]<br />
[[tr:Görüntü yöneticisi]]<br />
[[uk:Display manager]]<br />
[[zh-hans:Display manager]]<br />
[[zh-hant:Display manager]]<br />
{{Related articles start}}<br />
{{Related|Desktop environment}}<br />
{{Related|Window manager}}<br />
{{Related|Start X at login}}<br />
{{Related articles end}}<br />
<br />
A [[Wikipedia:X display manager (program type)|display manager]], or login manager, is typically a graphical user interface that is displayed at the end of the boot process in place of the default shell. There are various implementations of display managers, just as there are various types of [[window managers]] and [[desktop environments]]. There is usually a certain amount of customization and themeability available with each one.<br />
<br />
== List of display managers ==<br />
<br />
=== Console ===<br />
<br />
* {{App|[[CDM]]|Ultra-minimalistic, yet full-featured login manager written in Bash.|https://github.com/ghost1227/cdm|{{AUR|cdm-git}}}}<br />
* {{App|[[Console TDM]]|Extension for ''xinit'' written in pure Bash.|https://github.com/dopsi/console-tdm|{{AUR|console-tdm}}}}<br />
* {{App|[[nodm]]|Minimalistic display manager for automatic logins.|https://github.com/spanezz/nodm|{{Pkg|nodm}}}}<br />
* {{App|[[Ly]]|Experimental ncurses display manager.|https://github.com/cylgom/ly|{{AUR|ly-git}}}}<br />
<br />
=== Graphical ===<br />
<br />
* {{App|[[GDM]]|[[GNOME]] display manager.|https://wiki.gnome.org/Projects/GDM|{{Pkg|gdm}}}}<br />
* {{App|[[LightDM]]|Cross-desktop display manager, can use various front-ends written in any toolkit.|http://www.freedesktop.org/wiki/Software/LightDM|{{Pkg|lightdm}}}}<br />
* {{App|[[LXDM]]|[[LXDE]] display manager. Can be used independent of the LXDE desktop environment.|http://sourceforge.net/projects/lxdm/|{{Pkg|lxdm}}}}<br />
* {{App|[[SDDM]]|QML-based display manager and successor to KDE4's kdm; recommended for Plasma 5 and LXQt.|https://github.com/sddm/sddm|{{Pkg|sddm}}}}<br />
* {{App|[[SLiM]]|Lightweight and elegant graphical login solution. (discontinued)|http://sourceforge.net/projects/slim.berlios/|{{Pkg|slim}}}}<br />
* {{App|[[XDM]]|X display manager with support for XDMCP, host chooser.|http://www.x.org/archive/X11R7.5/doc/man/man1/xdm.1.html|{{Pkg|xorg-xdm}}}}<br />
<br />
== Loading the display manager ==<br />
<br />
To enable graphical login, [[enable]] the appropriate systemd service. For example, for [[SDDM]], enable {{ic|sddm.service}}.<br />
<br />
This should work out of the box. If not, you might have to reset a custom {{ic|default.target}} symlink to point to the default {{ic|graphical.target}}.<br />
<br />
After enabling [[SDDM]] a symlink {{ic|display-manager.service}} should be set in {{ic|/etc/systemd/system/}}. You may need to use {{ic|--force}} to override old symlinks.<br />
<br />
{{hc|$ file /etc/systemd/system/display-manager.service|<br />
/etc/systemd/system/display-manager.service: symbolic link to /usr/lib/systemd/system/sddm.service<br />
}}<br />
<br />
=== Using systemd-logind ===<br />
<br />
In order to check the status of your user session, you can use ''loginctl''. All [[polkit]] actions like suspending the system or mounting external drives will work out of the box.<br />
<br />
$ loginctl show-session $XDG_SESSION_ID<br />
<br />
== Session configuration ==<br />
<br />
Many display managers read available sessions from {{ic|/usr/share/xsessions/}} directory. It contains standard [http://standards.freedesktop.org/desktop-entry-spec/latest/ desktop entry files] for each DM/WM.<br />
<br />
To add/remove entries to your display manager's session list; create/remove the ''.desktop'' files in {{ic|/usr/share/xsessions/}} as desired. A typical ''.desktop'' file will look something like:<br />
<br />
[Desktop Entry]<br />
Name=Openbox<br />
Comment=Log in using the Openbox window manager (without a session manager)<br />
Exec=/usr/bin/openbox-session<br />
TryExec=/usr/bin/openbox-session<br />
Icon=openbox.png<br />
Type=Application<br />
<br />
===Run ~/.xinitrc as a session===<br />
Installing {{AUR|xinit-xsession}} will provide an option to run your .xinitrc as a session. Simply set 'xinitrc' as your session in your display manager's settings.<br />
<br />
=== Starting applications without a window manager ===<br />
<br />
You can also launch an application without any decoration, desktop, or window management. For example to launch {{AUR|google-chrome}} create a {{ic|web-browser.desktop}} file in {{ic|/usr/share/xsessions/}} like this:<br />
<br />
[Desktop Entry]<br />
Name=Web Browser<br />
Comment=Use a web browser as your session<br />
Exec=/usr/bin/google-chrome --auto-launch-at-startup<br />
TryExec=/usr/bin/google-chrome --auto-launch-at-startup<br />
Icon=google-chrome<br />
Type=Application<br />
<br />
In this case, once you login, the application set with {{ic|Exec}} will be launched immediately. When you close the application, you will be taken back to the login manager (same as logging out of a normal DE/WM).<br />
<br />
It is important to remember that most graphical applications are not intended to be launched this way and you might have manual tweaking to do or limitations to live with (there is no window manager, so do not expect to be able to move or resize ''any'' windows, including dialogs; nonetheless, you might be able to set the window geometry in the application's configuration files).<br />
<br />
See also [[xinitrc#Starting applications without a window manager]].<br />
<br />
== Tips and tricks ==<br />
<br />
=== Autostarting ===<br />
<br />
Most display managers source {{ic|/etc/xprofile}}, {{ic|~/.xprofile}} and {{ic|/etc/X11/xinit/xinitrc.d/}}. For more details, see [[xprofile]].<br />
<br />
=== Set the language ===<br />
<br />
{{Accuracy|This seems to change the locale of the user session but not of the DM itself. Probably better to link to [[Locale#Setting the locale]].}}<br />
<br />
For display managers that use [http://freedesktop.org/wiki/Software/AccountsService/ AccountsService] the display manager [[locale]] can be set by editing {{ic|/var/lib/AccountsService/users/$USER}}:<br />
<br />
[User]<br />
Language=''your_locale''<br />
<br />
where ''your_locale'' is a value such as {{ic|en_GB.UTF-8}}.<br />
<br />
Restart your display manager for the changes to take effect.</div>Ritkahttps://wiki.archlinux.org/index.php?title=Laptop/Lenovo&diff=485066Laptop/Lenovo2017-08-13T01:47:57Z<p>Ritka: /* Edge series */ corrected orthography for ThinkPad E545</p>
<hr />
<div>[[Category:Lenovo]]<br />
[[ja:ノートパソコン/Lenovo]]<br />
{{Laptops navigation}}<br />
<br><br />
== IBM/Lenovo ==<br />
<br />
=== ThinkPad ===<br />
<br />
==== 300 series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad 380ED || NA|| NA || NA || NA || No || NA || NA || NA || ||<br />
|-<br />
|}<br />
<br />
==== Edge series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo ThinkPad Edge E330]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad Edge E335]] || NA || Yes || Yes || Yes || Yes || NA || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad Edge E420s || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || SDcard (Yes), Webcam (Yes), Trackpoint (No) || <br />
|-<br />
| [[Lenovo ThinkPad Edge E430]] || Yes || Yes || Yes* || Yes* || Not tested || Yes || NA || NA || SD card (yes) || <br />
|-<br />
| [[Lenovo ThinkPad Edge E455]] || 2015.04.01 || Yes* || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad Edge E530 || Yes || Yes || Yes* || Yes* || Yes || Yes || NA || NA || SD card (yes), Finger Print (not tested) || <br />
|-<br />
| Lenovo ThinkPad Edge E540 || 2015.08.01 || Yes || Yes || Yes || Yes || Yes || Yes* || NA || SD card (yes), Finger Print (yes), touch pad and trackpoint (yes), Webcam (yes) || <br />
|-<br />
| Lenovo ThinkPad Edge E545 || NA || Yes || Yes || Yes || Yes* || Not tested || Yes || NA || SD card (yes), touch pad and trackpoint (yes) Webcam (yes) || wifi works only with {{Pkg|broadcom-wl-dkms}}<br />
|-<br />
|}<br />
<br />
==== L series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo ThinkPad L420 || Yes || Yes || Yes || Yes || Yes || Not tested || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad L430 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Trackpoint* ||<br />
|-<br />
| Lenovo ThinkPad L530 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Trackpoint*, Fingerprint reader ||<br />
|-<br />
|}<br />
<br />
==== P series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo ThinkPad P50]] || 2016.04 || Yes || Yes || Yes || Yes || Yes || Suspend working, hibernate not tested || NA || SD card (Yes), Webcam (Yes), Fingerprint Reader (No), || Wifi requires Kernel 4.3.3+ <br />
|-<br />
| [[Lenovo ThinkPad P70]] || 2016.04 || Yes || Yes || Yes || Yes || Yes || Suspend working, hibernate not tested || NA || SD card (Yes), Webcam (Yes), Fingerprint Reader (No), || Wifi requires Kernel 4.3.3+ <br />
|-<br />
|}<br />
<br />
==== R series ====<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad R50 || Yes || Yes || Yes || Yes || NA || Yes || Yes || Infrared* || ||<br />
|-<br />
| IBM ThinkPad R52 || Yes || Yes || Yes || Yes || NA || Yes || Yes || Infrared* || ||<br />
|-<br />
| Lenovo ThinkPad R60 || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
|}<br />
<br />
==== T series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| [[IBM ThinkPad T21]] || Yes* || Yes || Yes || NA || NA || Yes* || NA || NA || See below ||<br />
|-<br />
| [[IBM ThinkPad T23]] || Yes || Yes || Yes || NA || NA || Yes || NA || NA || ||<br />
|-<br />
| [[IBM ThinkPad T42]] || Yes || Yes || Yes || Yes || NA || Yes || NA || NA || ||<br />
|-<br />
| IBM ThinkPad T60 || Yes || Yes || Yes || Yes || Yes || Yes || ? || NA || ||<br />
|-<br />
| IBM ThinkPad T60p || Yes || Yes || Yes || Yes || Yes || Yes || ? || NA || ThinkFinger ||<br />
|-<br />
| [[IBM ThinkPad T61]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || || ||<br />
|-<br />
| IBM ThinkPad T61p || Yes || Yes || Yes || Yes || Yes || Yes || NA || || ||<br />
|-<br />
| [[Lenovo ThinkPad T400]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T400s]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| Lenovo ThinkPad T410 || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T420]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Card reader tested, no Fingerprint scanner||<br />
|-<br />
| [[Lenovo ThinkPad T420s]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || Card Reader ||<br />
|-<br />
| [[Lenovo ThinkPad T430]] || Yes || Yes || Yes || Yes || Yes || Yes* || Yes* || Not tested || ||<br />
|-<br />
| [[#Lenovo_ThinkPad_T440p|Lenovo ThinkPad T440p]] || Yes || Yes || Yes || Yes || Yes || Yes* || NA || NA || Card Reader || See below<br />
|-<br />
| [[Lenovo ThinkPad T440s]] || Yes || Yes || Yes || Yes || Yes* || ? || Yes || ? || || See wiki page for more details about wireless<br />
|-<br />
| [[Lenovo ThinkPad T450s]] || 2015.10.01 || Yes || Yes || Yes || Yes || Yes || ? || NA || SD Card reader; fingerprint scanner|| <br />
|-<br />
| [[Lenovo ThinkPad T460s]] || Yes || Yes || no beep || Yes || Yes || Yes || ? || NA || SD Card reader|| <br />
|-<br />
| [[Lenovo ThinkPad T470s]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD Card reader; fingerprint scanner|| <br />
|-<br />
| Lenovo ThinkPad T500 || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T520]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T530]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T550]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || DisplayPort ||<br />
|-<br />
| [[Lenovo ThinkPad T560]] || Yes || Yes || Yes || Yes || Yes || No* || Yes* || NA || MiniDP; Fingerprint scanner; Intel + Nvidia GPU; Card Reader || See special notes for the hardware specifications of this test device<br />
|-<br />
| [[Lenovo ThinkPad T570]] || Yes || Yes || Yes || Yes || Yes || ? || Yes* || NA || not yet fully tested || <br />
|}<br />
<br />
==== W series ====<br />
{{HCL/Laptops table header}}<br />
|-<br />
| Lenovo ThinkPad W510 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Yes), Webcam (Yes), Touchscreen (Yes), Fingeprint Reader (Not tested) || Tested April 2017 / Linux 4.10.8<br />
|-<br />
| Lenovo ThinkPad W540 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Yes), Webcam (Yes), Fingeprint Reader (Yes) || Tested April 2017 / Linux 4.10.8<br />
|-<br />
| Lenovo ThinkPad W550s || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Not tested), Webcam (Yes), Fingeprint Reader (Yes) ||<br />
|-<br />
|}<br />
<br />
==== X series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad X23 || Yes || Yes || Yes || NA || NA || Yes || NA || NA || ||<br />
|-<br />
| [[IBM ThinkPad X60s]] || Yes|| Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| Lenovo ThinkPad X61s || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD slot ||<br />
|-<br />
| [[Lenovo ThinkPad X100e]] || Yes|| Yes || Yes || Yes || Yes || Yes || Not tested || NA || SD card (Yes), Webcam (Yes) ||<br />
|-<br />
| [[Lenovo ThinkPad X200]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X200S]] || Yes || Yes || Yes || Yes || Yes || Not tested || NA || Not tested || Everything worked out of the box. However, fingerprint, SD card and webcam were not tested ||<br />
|-<br />
| [[Lenovo ThinkPad X201]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || ||<br />
|-<br />
| [[Lenovo ThinkPad X220]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Yes), Webcam (Yes) ||<br />
|-<br />
| [[Lenovo ThinkPad X230]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Yes), Webcam (Yes), UMTS Modem (Yes) ||<br />
|-<br />
| [[Lenovo ThinkPad X250]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Yes), Webcam (Yes), Fingerprint (yes) ||<br />
|-<br />
| [[Lenovo ThinkPad X260]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Yes), Webcam (Yes), Fingerprint (yes) ||<br />
|-<br />
| [[Lenovo ThinkPad X270]] || Yes || Yes || Yes || Yes || Yes || Not tested || Yes || NA || Webcam (yes) ||<br />
|-<br />
| [[Lenovo ThinkPad X1 Carbon]] || NA || Yes || Yes || Yes || Yes || Proprietary/nonfree || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X1 Carbon (Gen 2)]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X1 Carbon (Gen 3)]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X1 Carbon (Gen 4)]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X1 Carbon (Gen 5)]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
|}<br />
<br />
==== Yoga Series ====<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo ThinkPad Yoga 260]] || USB || Yes || Yes || Yes || Yes || Yes || Unknown || Yes || SD card (Yes), Webcam (Yes), Fingerprint Reader (Unknown), Touchscreen (Yes), Tablet (Partial), Accelerometer (No) || Wifi requires Kernel 4.3.3+<br />
|-<br />
|}<br />
<br />
== Lenovo ==<br />
<br />
=== IdeaPad ===<br />
<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo IdeaPad Flex 10]] || Yes || Yes* || Yes || NA || Yes || Yes || Yes || NA || Touchscreen* ||<br />
|-<br />
| [[Lenovo IdeaPad S10]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo IdeaPad S400 Touch]] || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || NA || ||<br />
|-<br />
| Lenovo IdeaPad U430p || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || NA || ||<br />
|-<br />
| Lenovo IdeaPad Y700 || 2015.12.01 || Yes || Yes* || Yes || Yes || Yes || Not tested || NA || Trackpad - [https://unix.stackexchange.com/questions/362165/lenovo-y700-elantech-touchpad-query-0x01-failed buggy] || [https://bugzilla.kernel.org/show_bug.cgi?id=151681 Trackpad requires pata_legacy to be blacklisted]<br />
|-<br />
| [[Lenovo IdeaPad Z580]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
|}<br />
<br />
=== B series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo B50 || NA || Yes || Yes || Yes || Yes || Not tested || Not tested || Not tested || ||<br />
|-<br />
| Lenovo B50-70 || Yes || Yes* ||Yes || Yes || Yes || Yes || Not tested || NA || See below* ||<br />
|-<br />
| Lenovo B450 || Yes || Yes ||Yes || Yes || Yes || NA || Not tested || NA || ||<br />
|-<br />
|}<br />
<br />
=== K series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo K450e || NA || Yes || Yes || Yes || Yes || Not tested || Yes || Not tested || ||<br />
|-<br />
|}<br />
<br />
=== N series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo N200 (3000) || Yes || Yes* || Yes || Yes || Yes || Yes* || NA || NA || See below ||<br />
|-<br />
|}<br />
<br />
=== S series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo S21e-20 || 2015.07.01 || Yes || Yes || NA || Yes* || ? || Yes || NA || SD Card (Yes), USB 3.0 (Yes), HDMI Out (?), Touchpad (Yes*) ||<br />
|-<br />
|}<br />
<br />
=== U Series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo U31-70 || 2015.10.01 || Yes || Yes || Yes || Yes* || Yes || Yes || NA || SD Card (Yes), USB 3.0 (Yes), HDMI Out (Yes), Touchpad (Yes), Webcam (Yes) ||<br />
|-<br />
|}<br />
<br />
== Special Notes (*): ==<br />
<br />
{{Accuracy|Lots of vague or unproven bugs/workarounds, poor writing}}<br />
<br />
=== Lenovo U31-70 ===<br />
Wireless needs {{Pkg|linux}} >= 4.3 and latest {{Pkg|linux-firmware}}, both packages are currently in testing. Copy one of the firmware blobs {{ic|eeprom_ar6320_2p1_NFA345i.bin}} or {{ic|eeprom_ar6320_2p1_NFA345i_highTX.bin}} from the windows driver to {{ic|/usr/lib/firmware/ath10k/QCA6174/hw2.1/board-pci-168c:0041:17aa:3545.bin}}.<br />
<br />
Wireless with firmware blobs from windows driver may no longer work on {{Pkg|linux}} >= 4.4. Download firmware blob https://github.com/kvalo/ath10k-firmware/blob/f428f53b36b144971c9c4c3d2ebd5fa8cae86c89/QCA6174/hw2.1/board-2.bin and copy it to {{ic|/usr/lib/firmware/ath10k/QCA6174/hw2.1/board-2.bin}}. Tested with {{Pkg|linux}} 4.4.5-1 and {{Pkg|linux-firmware}} 20160113.40e9ae8-1nu<br />
<br />
With packages {{Pkg|linux}} 4.6.1-2 and {{Pkg|linux-firmware}} 20160516.80d463b-1 being in stable, wireless works without any additional steps needed.<br />
<br />
=== Lenovo B50-70 ===<br />
* UEFI:<br />
** to be able to disable Secure Boot (necessary for dual boot, not needed for Linux only), you have to switch from "UEFI first" to "UEFI only" (or something like this) in UEFI setup menu; the Secure Boot option appears then on the Security tab<br />
** after UEFI update having Linux and Windows installed, the Linux bootloader ceased to be the default one, UEFI started to load Windows by default and it was impossible to select the Linux one in the UEFI boot menu and in the UEFI setup - reinstalling the bootloader helped; having no access to a boot media that supports UEFI, a solution might be also replacing the Windows EFI bootloader file with a Linux one temporalily, in order to be able to boot Linux from HDD<br />
** for the UEFI update, a Windows OS is needed<br />
* Touchpad:<br />
** Synaptics - works after installing Synaptics drivers from repo, possible to change behaviour (like reaction for double tap) according to your wish<br />
* Video:<br />
** in laptops with dual video card (Intel and ATI) - detects both, Intel is active as a default, not checked if it's possible at all to switch between them<br />
<br />
==== Operation with a HDD caddy ====<br />
When you install an SSD in the place of the plate HDD drive and you want to have your HDD still inside the laptop, it is possible to install it in the place of the optical drive in a special "HDD caddy". The optical drive is of 9 mm height, but a 9,5 mm caddy (ultra slim) fits in the slot. A caddy with a SATA interface is needed. It is difficult to separate the front bezel from the original optical drive (and opening its case does not help, but brings a danger of making a mess in the opening mechanism; the only option is just to pull the bezel using a bit of force, but you risk breaking the latches).<br />
<br />
While the HDD installed instead of the optical drive operates flawlessly in Windows, it wasn't going to work out of the box in Linux, at least in one case. The kernel tries to establish a connection with the disk, but fails to do it (''SATA link down'' entry in /var/log/messages). The solution is to force a 1.5 Gbps transfer speed (instead of 6 Gbps) by adding a ''libata.force='' kernel parameter. See [https://www.kernel.org/doc/Documentation/kernel-parameters.txt] for details.<br />
<br />
=== Lenovo K450e ===<br />
<br />
After installing Arch Linux and booting, a single beep may be heard. To disable this beep, press F1 during startup, then change Boot Priority to 'UEFI First', as well as enabling 'CSM'.<br />
<br />
=== ThinkPad X1 Carbon 3rd ===<br />
<br />
* http://natalian.org/archives/2015/02/18/Archlinux_on_a_Lenovo_X1C3/<br />
<br />
=== IBM ThinkPad T21 ===<br />
<br />
* Video: <br />
** Incapable of running DRM at 1024x768 and 24-bit color due to 8 MB VRAM. Must drop color or resolution to get DRM.<br />
** For whatever reason, external VGA output (for an external monitor) was disabled. This was fixed by doing this:<br />
*** {{ic|echo 1 > /proc/acpi/video/VID/DOS}}<br />
<br />
=== Lenovo 3000 N200 ===<br />
<br />
* Sound:<br />
** You may have to append <code>options snd_hda_intel model=lenovo</code> to <code>/etc/modprobe.d/modprobe.conf</code> for sound to work.<br />
<br />
=== IBM ThinkPad R52 ===<br />
<br />
* USB network tethering<br />
** Inbound networking via interface ''usb0'' works.<br />
<br />
=== Lenovo ThinkPad T430 ===<br />
<br />
* Bluetooth (0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad]) appears to be functional, even during standby or hibernation.<br />
<br />
=== Lenovo ThinkPad T440p ===<br />
<br />
* ClickPad: the whole trackpad clicks, and disabling the trackpad using older versions of synclient makes the trackpoint essentially unusable. This has been resolved in newer versions of {{Pkg|xf86-input-synaptics}}.<br />
** See [http://who-t.blogspot.com.au/2014/03/xorg-synaptics-support-for-lenovo-t440.html this article] and [http://who-t.blogspot.com.au/2013/12/lenovo-t440-touchpad-button.html previous version].<br />
** Install {{AUR|xf86-input-synlx40}}{{Broken package link|{{aur-mirror|xf86-input-synlx40}}}} and {{AUR|xf86-input-mtrack}} for alternative drivers.<br />
* Audio:<br />
** HDMI audio is the default audio output device. Consult the [[ALSA]] page for details on changing the default.<br />
** As the X100e/Mini10, it's possible to mute the headset and speaker outputs separately to the master. Muting the speaker output improves bass output on the headset port.<br />
** If the system fails to wake from sleep, it can lose sync with the internal audio card and speakers/headphones may fail to work. In this case, put the system to sleep, and wake it again and audio functionality should be restored. <br />
* The fingerprint sensor is a Validity VFS5011, which requires [https://github.com/abbradar/fprint_vfs5011 a patched fprintd] and is apparently highly unreliable.<br />
* thinkpad_acpi:<br />
** Controlling the Fn-Lock, Mute, Mic Mute or 'glowing I' LEDs is apparently not possible.<br />
** fan control does not seem to work.<br />
* Graphics and Video:<br />
** With the integrated GPU, [[xrandr]] can crash while attaching or detaching displays connected via the dock.<br />
** The built-in miniDisplayPort will sometimes spew I²C issues into the kernel log.<br />
** [[Hardware video acceleration]] is highly recommended as it performs significantly better than CPU decoding of large media files.<br />
** '''The BIOS should not be upgraded past version 1.14, as newer BIOSes cause memory corruption when used with Bumblebee.''' See [https://github.com/Bumblebee-Project/bbswitch/issues/78#issuecomment-42741698 Bumblebee GitHub]<br />
* Connectivity:<br />
** Bluetooth is ''extremely'' fragile. The controller works fine most of the time, but can cause the system to wedge totally on sleep/wake cycles, especially if a connection was active at sleep. Disable the controller using {{ic|bluetoothctl}} before sleeping.<br />
<br />
=== Lenovo ThinkPad T560 ===<br />
* Bluetooth couldn't be enabled (no out of the box experience)<br />
* No automatic brightness adjusting when switching power supply battery <-> AC<br />
<br />
<br />
* Hardware specifications of test device<br />
** CPU: Intel CORE i7-6600U @ 2.60GHz<br />
** GPU: Intel HD 520<br />
** GPU: Nvidia GeForce 940MX<br />
** WiFi: Intel 8260<br />
** Ethernet: Intel I219-LM<br />
** Card reader: Realtek RTS522A<br />
<br />
=== Lenovo S21e-20 ===<br />
* Tested with {{Pkg|broadcom-wl-dkms}} 802.11 wireless driver<br />
* Synaptics touchpad required 3 patches to {{Pkg|linux}}:drivers/hid/hid-rmi.c on 2015-07-26 ([https://bugs.freedesktop.org/show_bug.cgi?id=91102 bug report], [https://github.com/harisokanovic/archlinux-packages/commit/f4550c211ca7809ecf926f8074c7b7250a74bd92 kernel recipe patch]). The current 4.3 kernel includes these patches. You will also need to install the xf86_64-input-synaptics package([https://www.archlinux.org/packages/?name=xf86-input-synaptics]) <br />
<br />
==== tpacpi-bat ====<br />
<br />
There is an issue with tpacpi-bat not reporting the right value for the stop threshold. This seems to be related to a buggy BIOS and can not be fixed application wise. <br />
<br />
See https://github.com/teleshoes/tpacpi-bat/issues/44<br />
<br />
==== ThinkPad Edge E420s Delay with Space Bar====<br />
Solution: Update BIOS (at least 1.08).<br />
<br />
=== Lenovo IdeaPad Y700 ===<br />
* The subwoofer does not work out of the box and it seems that there is no solution yet.<br />
<br />
== See also ==<br />
* [http://www.thinkwiki.org/wiki Think wiki]</div>Ritkahttps://wiki.archlinux.org/index.php?title=Laptop/Lenovo&diff=485065Laptop/Lenovo2017-08-13T01:41:26Z<p>Ritka: /* Edge series */ added ThinkPad E545</p>
<hr />
<div>[[Category:Lenovo]]<br />
[[ja:ノートパソコン/Lenovo]]<br />
{{Laptops navigation}}<br />
<br><br />
== IBM/Lenovo ==<br />
<br />
=== ThinkPad ===<br />
<br />
==== 300 series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad 380ED || NA|| NA || NA || NA || No || NA || NA || NA || ||<br />
|-<br />
|}<br />
<br />
==== Edge series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo ThinkPad Edge E330]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad Edge E335]] || NA || Yes || Yes || Yes || Yes || NA || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad Edge E420s || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || SDcard (Yes), Webcam (Yes), Trackpoint (No) || <br />
|-<br />
| [[Lenovo ThinkPad Edge E430]] || Yes || Yes || Yes* || Yes* || Not tested || Yes || NA || NA || SD card (yes) || <br />
|-<br />
| [[Lenovo ThinkPad Edge E455]] || 2015.04.01 || Yes* || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad Edge E530 || Yes || Yes || Yes* || Yes* || Yes || Yes || NA || NA || SD card (yes), Finger Print (not tested) || <br />
|-<br />
| Lenovo ThinkPad Edge E540 || 2015.08.01 || Yes || Yes || Yes || Yes || Yes || Yes* || NA || SD card (yes), Finger Print (yes), touch pad and trackpoint (yes), Webcam (yes) || <br />
|-<br />
| Lenovo ThinkPad Edge E545 || NA || Yes || Yes || Yes || Yes* || Not tested || Yes || NA || SD card (yes), touch pad and trackpoinnt (yes) Webcam (yes) || wifi works only with {{Pkg|broadcom-wl-dkms}}<br />
|-<br />
|}<br />
<br />
==== L series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo ThinkPad L420 || Yes || Yes || Yes || Yes || Yes || Not tested || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad L430 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Trackpoint* ||<br />
|-<br />
| Lenovo ThinkPad L530 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Trackpoint*, Fingerprint reader ||<br />
|-<br />
|}<br />
<br />
==== P series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo ThinkPad P50]] || 2016.04 || Yes || Yes || Yes || Yes || Yes || Suspend working, hibernate not tested || NA || SD card (Yes), Webcam (Yes), Fingerprint Reader (No), || Wifi requires Kernel 4.3.3+ <br />
|-<br />
| [[Lenovo ThinkPad P70]] || 2016.04 || Yes || Yes || Yes || Yes || Yes || Suspend working, hibernate not tested || NA || SD card (Yes), Webcam (Yes), Fingerprint Reader (No), || Wifi requires Kernel 4.3.3+ <br />
|-<br />
|}<br />
<br />
==== R series ====<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad R50 || Yes || Yes || Yes || Yes || NA || Yes || Yes || Infrared* || ||<br />
|-<br />
| IBM ThinkPad R52 || Yes || Yes || Yes || Yes || NA || Yes || Yes || Infrared* || ||<br />
|-<br />
| Lenovo ThinkPad R60 || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
|}<br />
<br />
==== T series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| [[IBM ThinkPad T21]] || Yes* || Yes || Yes || NA || NA || Yes* || NA || NA || See below ||<br />
|-<br />
| [[IBM ThinkPad T23]] || Yes || Yes || Yes || NA || NA || Yes || NA || NA || ||<br />
|-<br />
| [[IBM ThinkPad T42]] || Yes || Yes || Yes || Yes || NA || Yes || NA || NA || ||<br />
|-<br />
| IBM ThinkPad T60 || Yes || Yes || Yes || Yes || Yes || Yes || ? || NA || ||<br />
|-<br />
| IBM ThinkPad T60p || Yes || Yes || Yes || Yes || Yes || Yes || ? || NA || ThinkFinger ||<br />
|-<br />
| [[IBM ThinkPad T61]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || || ||<br />
|-<br />
| IBM ThinkPad T61p || Yes || Yes || Yes || Yes || Yes || Yes || NA || || ||<br />
|-<br />
| [[Lenovo ThinkPad T400]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T400s]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| Lenovo ThinkPad T410 || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T420]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Card reader tested, no Fingerprint scanner||<br />
|-<br />
| [[Lenovo ThinkPad T420s]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || Card Reader ||<br />
|-<br />
| [[Lenovo ThinkPad T430]] || Yes || Yes || Yes || Yes || Yes || Yes* || Yes* || Not tested || ||<br />
|-<br />
| [[#Lenovo_ThinkPad_T440p|Lenovo ThinkPad T440p]] || Yes || Yes || Yes || Yes || Yes || Yes* || NA || NA || Card Reader || See below<br />
|-<br />
| [[Lenovo ThinkPad T440s]] || Yes || Yes || Yes || Yes || Yes* || ? || Yes || ? || || See wiki page for more details about wireless<br />
|-<br />
| [[Lenovo ThinkPad T450s]] || 2015.10.01 || Yes || Yes || Yes || Yes || Yes || ? || NA || SD Card reader; fingerprint scanner|| <br />
|-<br />
| [[Lenovo ThinkPad T460s]] || Yes || Yes || no beep || Yes || Yes || Yes || ? || NA || SD Card reader|| <br />
|-<br />
| [[Lenovo ThinkPad T470s]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD Card reader; fingerprint scanner|| <br />
|-<br />
| Lenovo ThinkPad T500 || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T520]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T530]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T550]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || DisplayPort ||<br />
|-<br />
| [[Lenovo ThinkPad T560]] || Yes || Yes || Yes || Yes || Yes || No* || Yes* || NA || MiniDP; Fingerprint scanner; Intel + Nvidia GPU; Card Reader || See special notes for the hardware specifications of this test device<br />
|-<br />
| [[Lenovo ThinkPad T570]] || Yes || Yes || Yes || Yes || Yes || ? || Yes* || NA || not yet fully tested || <br />
|}<br />
<br />
==== W series ====<br />
{{HCL/Laptops table header}}<br />
|-<br />
| Lenovo ThinkPad W510 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Yes), Webcam (Yes), Touchscreen (Yes), Fingeprint Reader (Not tested) || Tested April 2017 / Linux 4.10.8<br />
|-<br />
| Lenovo ThinkPad W540 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Yes), Webcam (Yes), Fingeprint Reader (Yes) || Tested April 2017 / Linux 4.10.8<br />
|-<br />
| Lenovo ThinkPad W550s || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Not tested), Webcam (Yes), Fingeprint Reader (Yes) ||<br />
|-<br />
|}<br />
<br />
==== X series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad X23 || Yes || Yes || Yes || NA || NA || Yes || NA || NA || ||<br />
|-<br />
| [[IBM ThinkPad X60s]] || Yes|| Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| Lenovo ThinkPad X61s || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD slot ||<br />
|-<br />
| [[Lenovo ThinkPad X100e]] || Yes|| Yes || Yes || Yes || Yes || Yes || Not tested || NA || SD card (Yes), Webcam (Yes) ||<br />
|-<br />
| [[Lenovo ThinkPad X200]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X200S]] || Yes || Yes || Yes || Yes || Yes || Not tested || NA || Not tested || Everything worked out of the box. However, fingerprint, SD card and webcam were not tested ||<br />
|-<br />
| [[Lenovo ThinkPad X201]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || ||<br />
|-<br />
| [[Lenovo ThinkPad X220]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Yes), Webcam (Yes) ||<br />
|-<br />
| [[Lenovo ThinkPad X230]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Yes), Webcam (Yes), UMTS Modem (Yes) ||<br />
|-<br />
| [[Lenovo ThinkPad X250]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Yes), Webcam (Yes), Fingerprint (yes) ||<br />
|-<br />
| [[Lenovo ThinkPad X260]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Yes), Webcam (Yes), Fingerprint (yes) ||<br />
|-<br />
| [[Lenovo ThinkPad X270]] || Yes || Yes || Yes || Yes || Yes || Not tested || Yes || NA || Webcam (yes) ||<br />
|-<br />
| [[Lenovo ThinkPad X1 Carbon]] || NA || Yes || Yes || Yes || Yes || Proprietary/nonfree || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X1 Carbon (Gen 2)]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X1 Carbon (Gen 3)]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X1 Carbon (Gen 4)]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X1 Carbon (Gen 5)]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
|}<br />
<br />
==== Yoga Series ====<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo ThinkPad Yoga 260]] || USB || Yes || Yes || Yes || Yes || Yes || Unknown || Yes || SD card (Yes), Webcam (Yes), Fingerprint Reader (Unknown), Touchscreen (Yes), Tablet (Partial), Accelerometer (No) || Wifi requires Kernel 4.3.3+<br />
|-<br />
|}<br />
<br />
== Lenovo ==<br />
<br />
=== IdeaPad ===<br />
<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo IdeaPad Flex 10]] || Yes || Yes* || Yes || NA || Yes || Yes || Yes || NA || Touchscreen* ||<br />
|-<br />
| [[Lenovo IdeaPad S10]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo IdeaPad S400 Touch]] || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || NA || ||<br />
|-<br />
| Lenovo IdeaPad U430p || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || NA || ||<br />
|-<br />
| Lenovo IdeaPad Y700 || 2015.12.01 || Yes || Yes* || Yes || Yes || Yes || Not tested || NA || Trackpad - [https://unix.stackexchange.com/questions/362165/lenovo-y700-elantech-touchpad-query-0x01-failed buggy] || [https://bugzilla.kernel.org/show_bug.cgi?id=151681 Trackpad requires pata_legacy to be blacklisted]<br />
|-<br />
| [[Lenovo IdeaPad Z580]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
|}<br />
<br />
=== B series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo B50 || NA || Yes || Yes || Yes || Yes || Not tested || Not tested || Not tested || ||<br />
|-<br />
| Lenovo B50-70 || Yes || Yes* ||Yes || Yes || Yes || Yes || Not tested || NA || See below* ||<br />
|-<br />
| Lenovo B450 || Yes || Yes ||Yes || Yes || Yes || NA || Not tested || NA || ||<br />
|-<br />
|}<br />
<br />
=== K series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo K450e || NA || Yes || Yes || Yes || Yes || Not tested || Yes || Not tested || ||<br />
|-<br />
|}<br />
<br />
=== N series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo N200 (3000) || Yes || Yes* || Yes || Yes || Yes || Yes* || NA || NA || See below ||<br />
|-<br />
|}<br />
<br />
=== S series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo S21e-20 || 2015.07.01 || Yes || Yes || NA || Yes* || ? || Yes || NA || SD Card (Yes), USB 3.0 (Yes), HDMI Out (?), Touchpad (Yes*) ||<br />
|-<br />
|}<br />
<br />
=== U Series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo U31-70 || 2015.10.01 || Yes || Yes || Yes || Yes* || Yes || Yes || NA || SD Card (Yes), USB 3.0 (Yes), HDMI Out (Yes), Touchpad (Yes), Webcam (Yes) ||<br />
|-<br />
|}<br />
<br />
== Special Notes (*): ==<br />
<br />
{{Accuracy|Lots of vague or unproven bugs/workarounds, poor writing}}<br />
<br />
=== Lenovo U31-70 ===<br />
Wireless needs {{Pkg|linux}} >= 4.3 and latest {{Pkg|linux-firmware}}, both packages are currently in testing. Copy one of the firmware blobs {{ic|eeprom_ar6320_2p1_NFA345i.bin}} or {{ic|eeprom_ar6320_2p1_NFA345i_highTX.bin}} from the windows driver to {{ic|/usr/lib/firmware/ath10k/QCA6174/hw2.1/board-pci-168c:0041:17aa:3545.bin}}.<br />
<br />
Wireless with firmware blobs from windows driver may no longer work on {{Pkg|linux}} >= 4.4. Download firmware blob https://github.com/kvalo/ath10k-firmware/blob/f428f53b36b144971c9c4c3d2ebd5fa8cae86c89/QCA6174/hw2.1/board-2.bin and copy it to {{ic|/usr/lib/firmware/ath10k/QCA6174/hw2.1/board-2.bin}}. Tested with {{Pkg|linux}} 4.4.5-1 and {{Pkg|linux-firmware}} 20160113.40e9ae8-1nu<br />
<br />
With packages {{Pkg|linux}} 4.6.1-2 and {{Pkg|linux-firmware}} 20160516.80d463b-1 being in stable, wireless works without any additional steps needed.<br />
<br />
=== Lenovo B50-70 ===<br />
* UEFI:<br />
** to be able to disable Secure Boot (necessary for dual boot, not needed for Linux only), you have to switch from "UEFI first" to "UEFI only" (or something like this) in UEFI setup menu; the Secure Boot option appears then on the Security tab<br />
** after UEFI update having Linux and Windows installed, the Linux bootloader ceased to be the default one, UEFI started to load Windows by default and it was impossible to select the Linux one in the UEFI boot menu and in the UEFI setup - reinstalling the bootloader helped; having no access to a boot media that supports UEFI, a solution might be also replacing the Windows EFI bootloader file with a Linux one temporalily, in order to be able to boot Linux from HDD<br />
** for the UEFI update, a Windows OS is needed<br />
* Touchpad:<br />
** Synaptics - works after installing Synaptics drivers from repo, possible to change behaviour (like reaction for double tap) according to your wish<br />
* Video:<br />
** in laptops with dual video card (Intel and ATI) - detects both, Intel is active as a default, not checked if it's possible at all to switch between them<br />
<br />
==== Operation with a HDD caddy ====<br />
When you install an SSD in the place of the plate HDD drive and you want to have your HDD still inside the laptop, it is possible to install it in the place of the optical drive in a special "HDD caddy". The optical drive is of 9 mm height, but a 9,5 mm caddy (ultra slim) fits in the slot. A caddy with a SATA interface is needed. It is difficult to separate the front bezel from the original optical drive (and opening its case does not help, but brings a danger of making a mess in the opening mechanism; the only option is just to pull the bezel using a bit of force, but you risk breaking the latches).<br />
<br />
While the HDD installed instead of the optical drive operates flawlessly in Windows, it wasn't going to work out of the box in Linux, at least in one case. The kernel tries to establish a connection with the disk, but fails to do it (''SATA link down'' entry in /var/log/messages). The solution is to force a 1.5 Gbps transfer speed (instead of 6 Gbps) by adding a ''libata.force='' kernel parameter. See [https://www.kernel.org/doc/Documentation/kernel-parameters.txt] for details.<br />
<br />
=== Lenovo K450e ===<br />
<br />
After installing Arch Linux and booting, a single beep may be heard. To disable this beep, press F1 during startup, then change Boot Priority to 'UEFI First', as well as enabling 'CSM'.<br />
<br />
=== ThinkPad X1 Carbon 3rd ===<br />
<br />
* http://natalian.org/archives/2015/02/18/Archlinux_on_a_Lenovo_X1C3/<br />
<br />
=== IBM ThinkPad T21 ===<br />
<br />
* Video: <br />
** Incapable of running DRM at 1024x768 and 24-bit color due to 8 MB VRAM. Must drop color or resolution to get DRM.<br />
** For whatever reason, external VGA output (for an external monitor) was disabled. This was fixed by doing this:<br />
*** {{ic|echo 1 > /proc/acpi/video/VID/DOS}}<br />
<br />
=== Lenovo 3000 N200 ===<br />
<br />
* Sound:<br />
** You may have to append <code>options snd_hda_intel model=lenovo</code> to <code>/etc/modprobe.d/modprobe.conf</code> for sound to work.<br />
<br />
=== IBM ThinkPad R52 ===<br />
<br />
* USB network tethering<br />
** Inbound networking via interface ''usb0'' works.<br />
<br />
=== Lenovo ThinkPad T430 ===<br />
<br />
* Bluetooth (0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad]) appears to be functional, even during standby or hibernation.<br />
<br />
=== Lenovo ThinkPad T440p ===<br />
<br />
* ClickPad: the whole trackpad clicks, and disabling the trackpad using older versions of synclient makes the trackpoint essentially unusable. This has been resolved in newer versions of {{Pkg|xf86-input-synaptics}}.<br />
** See [http://who-t.blogspot.com.au/2014/03/xorg-synaptics-support-for-lenovo-t440.html this article] and [http://who-t.blogspot.com.au/2013/12/lenovo-t440-touchpad-button.html previous version].<br />
** Install {{AUR|xf86-input-synlx40}}{{Broken package link|{{aur-mirror|xf86-input-synlx40}}}} and {{AUR|xf86-input-mtrack}} for alternative drivers.<br />
* Audio:<br />
** HDMI audio is the default audio output device. Consult the [[ALSA]] page for details on changing the default.<br />
** As the X100e/Mini10, it's possible to mute the headset and speaker outputs separately to the master. Muting the speaker output improves bass output on the headset port.<br />
** If the system fails to wake from sleep, it can lose sync with the internal audio card and speakers/headphones may fail to work. In this case, put the system to sleep, and wake it again and audio functionality should be restored. <br />
* The fingerprint sensor is a Validity VFS5011, which requires [https://github.com/abbradar/fprint_vfs5011 a patched fprintd] and is apparently highly unreliable.<br />
* thinkpad_acpi:<br />
** Controlling the Fn-Lock, Mute, Mic Mute or 'glowing I' LEDs is apparently not possible.<br />
** fan control does not seem to work.<br />
* Graphics and Video:<br />
** With the integrated GPU, [[xrandr]] can crash while attaching or detaching displays connected via the dock.<br />
** The built-in miniDisplayPort will sometimes spew I²C issues into the kernel log.<br />
** [[Hardware video acceleration]] is highly recommended as it performs significantly better than CPU decoding of large media files.<br />
** '''The BIOS should not be upgraded past version 1.14, as newer BIOSes cause memory corruption when used with Bumblebee.''' See [https://github.com/Bumblebee-Project/bbswitch/issues/78#issuecomment-42741698 Bumblebee GitHub]<br />
* Connectivity:<br />
** Bluetooth is ''extremely'' fragile. The controller works fine most of the time, but can cause the system to wedge totally on sleep/wake cycles, especially if a connection was active at sleep. Disable the controller using {{ic|bluetoothctl}} before sleeping.<br />
<br />
=== Lenovo ThinkPad T560 ===<br />
* Bluetooth couldn't be enabled (no out of the box experience)<br />
* No automatic brightness adjusting when switching power supply battery <-> AC<br />
<br />
<br />
* Hardware specifications of test device<br />
** CPU: Intel CORE i7-6600U @ 2.60GHz<br />
** GPU: Intel HD 520<br />
** GPU: Nvidia GeForce 940MX<br />
** WiFi: Intel 8260<br />
** Ethernet: Intel I219-LM<br />
** Card reader: Realtek RTS522A<br />
<br />
=== Lenovo S21e-20 ===<br />
* Tested with {{Pkg|broadcom-wl-dkms}} 802.11 wireless driver<br />
* Synaptics touchpad required 3 patches to {{Pkg|linux}}:drivers/hid/hid-rmi.c on 2015-07-26 ([https://bugs.freedesktop.org/show_bug.cgi?id=91102 bug report], [https://github.com/harisokanovic/archlinux-packages/commit/f4550c211ca7809ecf926f8074c7b7250a74bd92 kernel recipe patch]). The current 4.3 kernel includes these patches. You will also need to install the xf86_64-input-synaptics package([https://www.archlinux.org/packages/?name=xf86-input-synaptics]) <br />
<br />
==== tpacpi-bat ====<br />
<br />
There is an issue with tpacpi-bat not reporting the right value for the stop threshold. This seems to be related to a buggy BIOS and can not be fixed application wise. <br />
<br />
See https://github.com/teleshoes/tpacpi-bat/issues/44<br />
<br />
==== ThinkPad Edge E420s Delay with Space Bar====<br />
Solution: Update BIOS (at least 1.08).<br />
<br />
=== Lenovo IdeaPad Y700 ===<br />
* The subwoofer does not work out of the box and it seems that there is no solution yet.<br />
<br />
== See also ==<br />
* [http://www.thinkwiki.org/wiki Think wiki]</div>Ritkahttps://wiki.archlinux.org/index.php?title=Talk:GnuPG&diff=434685Talk:GnuPG2016-05-11T18:58:18Z<p>Ritka: /* inaccuracies in #Encrypt_and_decrypt section */</p>
<hr />
<div>== <s>Error with warning under ''Backup your private key'' </s>==<br />
<br />
I took notice of the warning under the header ''Backup your private key'' and I am pretty certain it is an error. <br />
<br />
Exported secret keys are encrypted using your paraphrase. See the attached link.<br />
<br />
http://lists.gnupg.org/pipermail/gnupg-users/2012-June/044606.html<br />
<br />
Ever notice how you don't need to enter your paraphrase to export a secret key? It's because you're not decrypting it. The secret key you're exporting is still encrypted! Try exporting a key, then import it on another machine (if possible)... Notice that you still need your passphrase on the new machine to actually use the key because the secret key you imported was encrypted. You can't do anything with an encrypted private key. GnuPG will NEVER export a unencrypted private key unless you explicitly ask it to using ''--export-reset-subkey-password'' or similar option.<br />
<br />
http://stackoverflow.com/questions/9981099/are-exported-private-keys-in-gpg-still-encrypted<br />
<br />
I did see some conflicting information however saying that exported private keys aren't protected. However, they are. I know they are. Look at the source code. Inspect the exported key's packets. It's encrypted. GnuPG isn't that stupid.<br />
<br />
I think this warning is an error, and is causing many people to be hesitant to backup their keys.<br />
<br />
GnuPG exported secret keys are always encrypted on export. If it wasn't the case, you'd need your passphrase before export to get the raw unencrypted key. In order to preform crypto operations on someone's behalf (especially signing), like the warning states, you'd need their passphrase to the exported secret key.<br />
<br />
Before I go ahead and change this page, I just wanted to get some input and see if I'm wrong.<br />
<br />
[[User:JCBird1012|JCBird1012]] ([[User talk:JCBird1012|talk]]) 13:03, 27 April 2016 (UTC) <br />
<br />
:Hi, thanks for pointing it out. You are right, I think it was a simple hickup referencing old gnugpg releases. The references you use above are not ideal for the same reason, by the way. In particular the first link contains some fallacies in its second paragraph. Also note gnugpg will indeed regain functionality to export the secret-key ''without'' the passphrase sometime: [https://bugs.gnupg.org/gnupg/issue2070], [https://bugs.gnupg.org/gnupg/issue2324]. .. Please don't call them stupid for it now ;) .. as so often security is torn by everyday use cases, it's simple as that. <br />
:I have changed the warning with [https://wiki.archlinux.org/index.php?title=GnuPG&type=revision&diff=433009&oldid=433008 this edit]. How do you like it? You are welcome to edit it freely to improve on it (applies to anything in this wiki, just make sure to [[ArchWiki:Contributing#Always properly use the edit summary]], so that others understand the what and why). <br />
:--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:29, 28 April 2016 (UTC)<br />
<br />
::Thanks for editing that. It's great! Hopefully many users now feel comfortable exporting and backing up their private key to a secure medium (just in case disaster strikes).<br />
<br />
::Just a quick note. The first bug, while an issue, is mainly irrelevant to the majority to GnuPG users, since it only affects the 2.1 release, which is the modern version. In many distributions, this version is not installed, or if it is, is not the primary version used. The second issue only applies if the key doesn't have a passphrase. This again only affects a small set of GnuPG users as many users choose to use a passphrase with their key (assuming they're aware of good key security practices). GnuPG will prompt the user, confirming that a passphrase isn't desired. But thank you for pointing those issues out, nonetheless (I didn't know they existed before now.) <br />
::While bugs do exist, I'm sure an issue as big as exporting private keys in plaintext would be taken extremely seriously and patched quickly by the GnuPG developers. <br />
<br />
::Though you shouldn't fully trust any software, many people rely on GnuPG every single day to protect what matters to them. It's an imortant piece of software to many people, and as a community, we should take every step to ensure the accuracy of the information we're sharing. I might have come off slightly strong in my first post, but I can get that way with serious matters ;). <br />
<br />
::Thanks for all your help Indigo!<br />
<br />
:::[[User:JCBird1012|JCBird1012]] ([[User talk:JCBird1012|talk]]) 20:21, 6 May 2016 (UTC)<br />
<br />
:::Ok, great, thanks for feedback. Closing this item then. Quick reply regarding releases: We don't usually reference release information, it only complicates reading flow. One of the benefits Arch users cherish is having latest stable software releases rolled out to them very fast. It is only natural ArchWiki can be expected and strives to contain up-to-date info everywhere (& thanks to our many contributors who care that works pretty well). For this edit it seemed useful to reference release info, to notify about a new feature with different application behaviour, but it is one of few exceptions really. If you (/anyone) see something else which is outdated but can't fix it right away, putting a status template like [[Template:Out of date]] or [[Template:Accuracy]] also helps. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:50, 7 May 2016 (UTC)<br />
<br />
== inaccuracies in #Encrypt_and_decrypt section ==<br />
<br />
Hey, I am not quite sure about the correctness about some statements in the mentioned sections. At least they are inaccurate about the basic principles of public-key cryptography, wich is in my opinion the main usage of pgp.<br />
<br />
The points I am not sure about and where I would like to hear someone elses opinion are:<br />
1) "When encrypting or decrypting it is possible to have more than one private key in use."<br />
I think that is not about private but about public keys. You can of course have multiple private keys in you keyring, but I don't know how you can need more than one to decrypt a file.<br />
<br />
2) According to 1) the rest of the pragraph doesn't make much sense to me, too. It's true that the '-u' option lets you chose the private key to use. But usually an encrypted file contains informations about the keys it is encrypted with, so you won't need that in most of the cases.<br />
<br />
3) "$ gpg --encrypt --armor doc" This command seems also a bit odd to me, because it doesn't specify a recipient. When I enter it gpg complains to me about that and asks me interactively to specify a recipient. I mean there is nothing wrong about it, but it does not convey the concept of public-key cryptography. At least it should be stated, that gpg will ask you for the recipients.<br />
<br />
Maybe that wiki page shall not be a tutorial on public-key cryptography, but if you are new to that, you are very likely to be confused by these inaccuracies, I think.<br />
<br />
If there were any intentions behind that section which I have missed, I would appreciate to hear them. Otherwise I would try to rewrite<br />
--[[User:Ritka|Ritka]] ([[User talk:Ritka|talk]]) 12:04, 7 May 2016 (UTC)<br />
<br />
:Hi, I'd say the intention behind the examples in [[GnuPG#Encrypt and decrypt]] is to keep it simple, because - as you note - the underlying concepts are too much to more than touch upon in a short section about usage. I agree with you the first sentence can be misleading for users not versed in it (what is meant imo is that often different keys/subkeys are used). I think it would be enough to rephrase it to make that part clearer along what you write. The examples could even stay the same, just adding that gpg will ask for a recipient (encrypt) due to the underlying encryption concept and reference the reader to the typical Alice&Bob examples elsewhere (e.g. [[wikipedia:Public-key cryptography]]). Adding then that if one uses the own key-id as recipient, the note about using gpg to protect self-encrypted docs could be merged/lead over to. <br />
:These are just my thoughts on it, please don't refrain from rewriting it in the way you think what is a good basic usage example. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 14:55, 10 May 2016 (UTC)<br />
<br />
:1) This section is about private keys and is correct, but I agree that this is far from clear. See [http://www.dewinter.com/gnupg_howto/english/GPGMiniHowto-4.html#ss4.1].<br />
:2) It only really applies to the decryption part, although you could use a private key to sign in addition to the encryption(not covered here), so perhaps it should be moved to just it to the decryption section.<br />
:3) +1 It seems like the recipient was put in the following tip, but should be put in the main section.<br />
:-- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]), [[ArchWiki:Maintainers|ArchWiki Maintainer]] 23:57, 10 May 2016 (UTC)<br />
<br />
:: I've done some editing now. I did my best but since I am noT a native speaker, it would be nice if someone just could check through.<br />
:: I omited all the whole '-u' thing, because this option seems to be only relevant to signing (according to the man page of gpg: {{ic|-u Use name as the key to sign with. Note that ''etc.''}}). I guess, if there is no information about the recipient in the encrypted file, gpg will just try out every private key in your keyring, so you do not need to specify it usign '-u'.<br />
:: --[[User:Ritka|Ritka]] ([[User talk:Ritka|talk]]) 18:58, 11 May 2016 (UTC)</div>Ritkahttps://wiki.archlinux.org/index.php?title=GnuPG&diff=434684GnuPG2016-05-11T18:40:59Z<p>Ritka: /* Encrypt and decrypt */ added '-o' option to the example, otherwise gpg will write decrypted data to stdout. also added an explanation of the command below.</p>
<hr />
<div>[[Category:Encryption]]<br />
[[es:GnuPG]]<br />
[[ja:GnuPG]]<br />
[[ru:GnuPG]]<br />
[[zh-cn:GnuPG]]<br />
{{Related articles start}}<br />
{{Related|pacman/Package signing}}<br />
{{Related|Disk encryption}}<br />
{{Related|List of applications/Security#Encryption, signing, steganography}}<br />
{{Related articles end}}<br />
<br />
According to the [http://www.gnupg.org official website]:<br />
<br />
:GnuPG is a complete and free implementation of the OpenPGP standard as defined by RFC4880 (also known as [[Wikipedia:PGP|PGP]]). GnuPG allows to encrypt and sign your data and communication, features a versatile key management system as well as access modules for all kinds of public key directories. GnuPG, also known as GPG, is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries are available. Version 2 of GnuPG also provides support for S/MIME and Secure Shell (ssh).<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|gnupg}} package.<br />
<br />
This will also install {{Pkg|pinentry}}, a collection of simple PIN or passphrase entry dialogs which GnuPG uses for passphrase entry. Which ''pinentry'' dialog is used is determined by the symbolic link {{ic|/usr/bin/pinentry}}, which by default points to {{ic|/usr/bin/pinentry-gtk-2}}.<br />
<br />
If you want to use a graphical frontend or program that integrates with GnuPG, see [[List of applications/Security#Encryption, signing, steganography]].<br />
<br />
== Configuration ==<br />
<br />
=== Directory location ===<br />
{{ic|$GNUPGHOME}} is used by GnuPG to point to the directory where its configuration files are stored. By default {{ic|$GNUPGHOME}} is not set and your {{ic|$HOME}} is used instead; thus, you will find a {{ic|~/.gnupg}} directory right after installation. <br />
<br />
To change the default location, either run gpg this way {{ic|$ gpg --homedir ''path/to/file''}} or set {{ic|GNUPGHOME}} in one of your regular [[startup files]].<br />
<br />
=== Configuration files ===<br />
<br />
The default configuration files are {{ic|~/.gnupg/gpg.conf}} and {{ic|~/.gnupg/dirmngr.conf}}. <br />
<br />
By default, the gnupg directory has its [[permissions]] set to {{ic|700}} and the files it contains have their permissions set to {{ic|600}}. Only the owner of the directory has permission to read, write, and access the files. This is for security purposes and should not be changed. In case this directory or any file inside it does not follow this security measure, you will get warnings about unsafe file and home directory permissions.<br />
<br />
Append to these files any long options you want. Do not write the two dashes, but simply the name of the option and required arguments. You will find skeleton files in {{ic|/usr/share/gnupg}}. These files are copied to {{ic|~/.gnupg}} the first time gpg is run if they do not exist there. Other examples are found in [[#See also]].<br />
<br />
Additionally, [[pacman]] uses a different set of configuration files for package signature verification. See [[Pacman/Package signing]] for details.<br />
<br />
=== Default options for new users ===<br />
<br />
If you want to setup some default options for new users, put configuration files in {{ic|/etc/skel/.gnupg/}}. When the new user is added in system, files from here will be copied to its GnuPG home directory. There is also a simple script called ''addgnupghome'' which you can use to create new GnuPG home directories for existing users:<br />
<br />
# addgnupghome user1 user2<br />
<br />
This will add the respective {{ic|/home/user1/.gnupg}} and {{ic|/home/user2/.gnupg}} and copy the files from the skeleton directory to it. Users with existing GnuPG home directory are simply skipped.<br />
<br />
== Usage ==<br />
<br />
{{Note|Whenever a ''{{ic|<user-id>}}'' is required in a command, it can be specified with your key ID, fingerprint, a part of your name or email address, etc. GnuPG is flexible on this.<br />
}}<br />
<br />
=== Create key pair ===<br />
<br />
Generate a key pair by typing in a terminal:<br />
<br />
$ gpg --full-gen-key<br />
<br />
{{Tip|Use the {{ic|--expert}} option for getting alternative ciphers like [[wikipedia:Elliptic_curve_cryptography|ECC]].}}<br />
<br />
The command will prompt for answers to several questions. For general use most people will want: <br />
<br />
* the RSA (sign only) and a RSA (encrypt only) key.<br />
* a keysize of the default value (2048). A larger keysize of 4096 "gives us almost nothing, while costing us quite a lot"[https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096].<br />
* an expiration date. A period of a year is good enough for the average user. This way even if access is lost to the keyring, it will allow others to know that it is no longer valid. Later, if necessary, the expiration date can be extended without having to re-issue a new key.<br />
* your name and email address. You can add multiple identities to the same key later (''e.g.'', if you have multiple email addresses you want to associate with this key).<br />
* ''no'' optional comment. Since the semantics of the comment field are [https://lists.gnupg.org/pipermail/gnupg-devel/2015-July/030150.html not well-defined], it has limited value for identification.<br />
* [[Security#Choosing_secure_passwords|a secure passphrase]].<br />
<br />
{{Note|The name and email address you enter here will be seen by anybody who imports your key.}}<br />
<br />
=== List keys ===<br />
<br />
To list keys in your public key ring:<br />
<br />
$ gpg --list-keys<br />
<br />
To list keys in your secret key ring:<br />
<br />
$ gpg --list-secret-keys<br />
<br />
=== Export your public key ===<br />
<br />
In order for others to send encrypted messages to you, they need your public key.<br />
<br />
To generate an ASCII version of your public key (''e.g.'' to distribute it by e-mail):<br />
<br />
$ gpg --armor --output ''public.key'' --export ''<user-id>''<br />
<br />
Alternatively, or in addition, you can [[#Use a keyserver]] to share your key. <br />
<br />
{{Tip|Add {{ic|--no-emit-version}} to avoid printing the version number, or add the corresponding setting to your configuration file.}}<br />
<br />
=== Import a key ===<br />
<br />
In order to encrypt messages to others, as well as verify their signatures, you need their public key. To import a public key with file name {{ic|''public.key''}} to your public key ring:<br />
<br />
$ gpg --import ''public.key''<br />
<br />
Alternatively, [[#Use a keyserver]] to find a public key.<br />
<br />
=== Use a keyserver ===<br />
<br />
You can register your key with a public PGP key server, so that others can retrieve your key without having to contact you directly:<br />
<br />
$ gpg --send-keys ''<key-id>''<br />
<br />
To find out details of a key on the keyserver, without importing it, do:<br />
<br />
$ gpg --search-keys ''<key-id>''<br />
<br />
To import a key from a key server:<br />
<br />
$ gpg --recv-keys ''<key-id>''<br />
<br />
{{Warning|Anyone can send keys to a keyserver, so you should not trust that the key you download actually belongs to the individual listed. You should verify the authenticity of the retrieved public key by comparing its fingerprint with one that the owner published on an independent source, such as their own blog or website, or contacting them by email, over the phone or in person. Using multiple authentication sources will increase the level of trust you can give to the downloaded key. See [[Wikipedia:Public key fingerprint]] for more information.}}<br />
<br />
{{Tip|<br />
* Adding {{ic|keyserver-options auto-key-retrieve}} to {{ic|gpg.conf}} will automatically fetch keys from the key server as needed.<br />
* An alternative key server is {{ic|pool.sks-keyservers.net}} and can be specified with {{ic|keyserver}} in {{ic|dirmngr.conf}}.; see also [[wikipedia:Key server (cryptographic)#Keyserver examples]].<br />
* You can connect to the keyserver over [[Tor]] using {{ic|--use-tor}}. {{ic|hkp://jijrk5u4osbsr34t5.onion}} is the onion address for the sks-keyservers pool. [https://gnupg.org/blog/20151224-gnupg-in-november-and-december.html See this GnuPG blog post] for more information.<br />
* You can connect to a keyserver using a proxy by setting the {{ic|http_proxy}} environment variable and setting {{ic|honor-http-proxy}} in {{ic|dirmngr.conf}}. Alternatively, set {{ic|http-proxy ''host[:port]''}} in {{ic|dirmngr.conf}}, overriding the {{ic|http_proxy}} environment variable.}}<br />
<br />
=== Encrypt and decrypt ===<br />
<br />
gpg's main usage is public-key cryptography (see [[Wikipedia:Public-key cryptography]]). That means, you usually use a users public key to encrypt files and you use your private key to decrypt them.<br />
<br />
To encrypt a file with the name ''doc'', use:<br />
<br />
$ gpg -e -r ''<user-id>'' ''doc''<br />
<br />
where ''<user-id>'' should refer to the user who shall be able to decrypt the file. Note that you need to import the users public key before.<br />
<br />
{{Tip|<br />
* Add {{ic|--armor}} to encrypt a file using ASCII armor (suitable for copying and pasting a message in text format)<br />
* Use {{ic|-R ''<user-id>''}} or {{ic|--hidden-recipient ''<user-id>''}} instead of {{ic|-r}} to not put the recipient key IDs in the encrypted message. This helps to hide the receivers of the message and is a limited countermeasure against traffic analysis.<br />
* Add {{ic|--no-emit-version}} to avoid printing the version number, or add the corresponding setting to your configuration file.}}<br />
<br />
{{Note|You can use gnupg to encrypt your sensitive documents by using your own user-id as recipient, but only individual files at a time. If you want to encrypt directories or a whole file-system you should consider using [[TrueCrypt]] or [[EncFS]], though you can always tarball various files and then encrypt them.}}<br />
<br />
To decrypt a file with the name ''doc.gpg'' encrypted with your public key, use:<br />
<br />
$ gpg -o ''doc.txt'' -d ''doc.gpg''<br />
<br />
gpg will prompt you for your passphrase and then decrypt and write the data from ''doc.gpg'' to ''doc.txt''. If you omit the {{ic|-o}} option, gpg will write the decrypted data to stdout.<br />
<br />
== Key maintenance ==<br />
<br />
=== Backup your private key ===<br />
<br />
To backup your private key do the following:<br />
<br />
$ gpg --export-secret-keys --armor ''<user-id>'' > ''privkey.asc''<br />
<br />
Note that ''gpg'' release 2.1 changed default behaviour so that the above command enforces a passphrase protection, even if you deliberately chose not to use one on key creation. This is because otherwise anyone who gains access to the above exported file would be able to encrypt and sign documents as if they were you ''without'' needing to know your passphrase. <br />
<br />
{{Warning|The passphrase is usually the weakest link in protecting your secret key. Place the private key in a safe place on a different system/device, such as a locked container or encrypted drive. It is the only safety you have to regain control to your keyring in case of, for example, a drive failure, theft or worse.}}<br />
<br />
=== Edit your key ===<br />
<br />
Running the {{ic|gpg --edit-key ''<user-id>''}} command will present a menu which enables you to do most of your key management related tasks.<br />
<br />
Some useful commands in the edit key sub menu:<br />
> passwd # change the passphrase<br />
> clean # compact any user ID that is no longer usable (e.g revoked or expired)<br />
> revkey # revoke a key<br />
> addkey # add a subkey to this key<br />
> expire # change the key expiration time<br />
<br />
Type {{ic|help}} in the edit key sub menu for more commands.<br />
<br />
{{Tip|If you have multiple email accounts you can add each one of them as an identity, using {{ic|adduid}} command. You can then set your favourite one as {{ic|primary}}.}}<br />
<br />
=== Exporting subkey ===<br />
<br />
If you plan to use the same key across multiple devices, you may want to strip out your master key and only keep the bare minimum encryption subkey on less secure systems.<br />
<br />
First, find out which subkey you want to export.<br />
<br />
$ gpg -K<br />
<br />
Select only that subkey to export.<br />
<br />
$ gpg -a --export-secret-subkeys [subkey id]! > /tmp/subkey.gpg<br />
<br />
{{Warning|If you forget to add the !, all of your subkeys will be exported.}}<br />
<br />
At this point you could stop, but it is most likely a good idea to change the passphrase as well. Import the key into a temporary folder. <br />
<br />
$ gpg --homedir /tmp/gpg --import /tmp/subkey.gpg<br />
$ gpg --homedir /tmp/gpg --edit-key ''<user-id>''<br />
> passwd<br />
> save<br />
$ gpg --homedir /tmp/gpg -a --export-secret-subkeys [subkey id]! > /tmp/subkey.altpass.gpg<br />
<br />
{{Note|You will get a warning that the master key was not available and the password was not changed, but that can safely be ignored as the subkey password was.}}<br />
<br />
At this point, you can now use {{ic|/tmp/subkey.altpass.gpg}} on your other devices.<br />
<br />
=== Rotating subkeys ===<br />
<br />
{{Warning|'''Never''' delete your expired or revoked subkeys unless you have a good reason. Doing so will cause you to lose the ability to decrypt files encrypted with the old subkey. Please '''only''' delete expired or revoked keys from other users to clean your keyring.}}<br />
<br />
If you have set your subkeys to expire after a set time, you can create new ones. Do this a few weeks in advance to allow others to update their keyring.<br />
<br />
{{Note|You do not need to create a new key simply because it is expired. You can extend the expiration date.}}<br />
<br />
Create new subkey (repeat for both signing and encrypting key)<br />
<br />
$ gpg --edit-key ''<user-id>''<br />
> addkey<br />
<br />
And answer the following questions it asks (see previous section for suggested settings).<br />
<br />
Save changes<br />
<br />
> save<br />
<br />
Update it to a keyserver.<br />
<br />
$ gpg --keyserver pgp.mit.edu --send-keys ''<user-id>''<br />
<br />
{{Note|Revoking expired subkeys is unnecessary and arguably bad form. If you are constantly revoking keys, it may cause others to lack confidence in you.}}<br />
<br />
== Signatures ==<br />
<br />
Signatures certify and timestamp documents. If the document is modified, verification of the signature will fail. Unlike encryption which uses public keys to encrypt a document, signatures are created with the user's private key. The recipient of a signed document then verifies the signature using the sender's public key.<br />
<br />
=== Sign a file ===<br />
<br />
To sign a file use the {{ic|--sign}} or {{ic|-s}} flag:<br />
<br />
$ gpg --output ''doc.sig'' --sign ''doc''<br />
<br />
The above also encrypts the file and stores it in binary format.<br />
<br />
=== Clearsign a file or message ===<br />
<br />
To sign a file without compressing it into binary format use:<br />
<br />
$ gpg --clearsign ''doc''<br />
<br />
This wraps the document into an ASCII-armored signature, but does not modify the document.<br />
<br />
=== Make a detached signature ===<br />
<br />
To create a separate signature file to be distributed separately from the document or file itself, use the {{ic|--detach-sig}} flag:<br />
<br />
$ gpg --output ''doc.sig'' --detach-sig ''doc''<br />
<br />
This method is often used in distributing software projects to allow users to verify that the program has not been modified by a third part.<br />
<br />
=== Verify a signature ===<br />
<br />
To verify a signature use the {{ic|--verify}} flag:<br />
<br />
$ gpg --verify ''doc.sig''<br />
<br />
where {{ic|''doc.sig''}} is the signature you wish to verify.<br />
<br />
To verify and decrypt a file at the same time, use the {{ic|--decrypt}} flag as you normally would in decrypting a file.<br />
<br />
If you are verifying a detached signature, both the file and the signature must be present when verifying. For example, to verify Arch Linux's latest iso you would do:<br />
<br />
$ gpg --verify ''archlinux-<version>-dual.iso.sig''<br />
<br />
where {{ic|''archlinux-<version>-dual.iso''}} must be located in the same directory.<br />
<br />
== gpg-agent ==<br />
<br />
''gpg-agent'' is mostly used as daemon to request and cache the password for the keychain. This is useful if GnuPG is used from an external program like a mail client.<br />
<br />
Starting with GnuPG 2.1.0 the use of ''gpg-agent'' is required. ''gpg-agent'' is started on-demand by the GnuPG tools, so there is usually no reason to start it manually.<br />
<br />
=== Configuration ===<br />
<br />
gpg-agent can be configured via {{ic|~/.gnupg/gpg-agent.conf}} file. The configuration options are listed in {{ic|man gpg-agent}}. For example you can change cache ttl for unused keys:<br />
<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
default-cache-ttl 3600<br />
}}<br />
<br />
{{Tip|To cache your passphrase for the whole session, please run the following command:<br />
$ /usr/lib/gnupg/gpg-preset-passphrase --preset XXXXXX<br />
<br />
where XXXX is the keygrip. You can get its value when running {{ic|gpg --with-keygrip -K}}. Passphrase will be stored until {{ic|gpg-agent}} is restarted. If you set up {{ic|default-cache-ttl}} value, it will take precedence.<br />
}}<br />
<br />
=== Reload the agent ===<br />
<br />
After changing the configuration, reload the agent using ''gpg-connect-agent'':<br />
<br />
$ gpg-connect-agent reloadagent /bye<br />
<br />
The command should print {{ic|OK}}.<br />
<br />
=== pinentry ===<br />
<br />
Finally, the agent needs to know how to ask the user for the password. This can be set in the gpg-agent configuration file.<br />
<br />
The default uses a gtk dialog. There are other options - see {{ic|info pinentry}}. To change the dialog implementation set {{ic|pinentry-program}} configuration option:<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
<br />
# PIN entry program<br />
# pinentry-program /usr/bin/pinentry-curses<br />
# pinentry-program /usr/bin/pinentry-qt<br />
# pinentry-program /usr/bin/pinentry-kwallet<br />
<br />
pinentry-program /usr/bin/pinentry-gtk-2<br />
}}<br />
<br />
{{Tip|For using {{ic|/usr/bin/pinentry-kwallet}} you have to install the {{Pkg|kwalletcli}} package.}}<br />
<br />
After making this change, reload the gpg-agent.<br />
<br />
=== Start gpg-agent with systemd user ===<br />
<br />
It is possible to use the [[Systemd/User]] facilities to start the agent.<br />
<br />
Create a systemd unit file:<br />
<br />
{{hc|~/.config/systemd/user/gpg-agent.service|2=<br />
[Unit]<br />
Description=GnuPG private key agent<br />
IgnoreOnIsolate=true<br />
<br />
[Service]<br />
Type=forking<br />
ExecStart=/usr/bin/gpg-agent --daemon<br />
Restart=on-abort<br />
<br />
[Install]<br />
WantedBy=default.target<br />
}}<br />
<br />
{{Note|If you use non-default value for the [[#GNUPGHOME]] environment variable, you need to pass it to the service. See [[systemd/User#Environment variables]] for details.}}<br />
<br />
=== Unattended passphrase ===<br />
<br />
Starting with GnuPG 2.1.0 the use of gpg-agent and pinentry is required, which may break backwards compatibility for passphrases piped in from STDIN using the {{ic|--passphrase-fd 0}} commandline option. In order to have the same type of functionality as the older releases two things must be done:<br />
<br />
First, edit the gpg-agent configuration to allow ''loopback'' pinentry mode:<br />
<br />
{{hc|1=~/.gnupg/gpg-agent.conf|2=<br />
allow-loopback-pinentry<br />
}}<br />
<br />
Restart the gpg-agent process if it is running to let the change take effect.<br />
<br />
Second, either the application needs to be updated to include a commandline parameter to use loopback mode like so:<br />
<br />
$ gpg --pinentry-mode loopback ...<br />
<br />
...or if this is not possible, add the option to the configuration:<br />
<br />
{{hc|1=~/.gnupg/gpg.conf|2=<br />
pinentry-mode loopback<br />
}}<br />
<br />
{{Note|The upstream author indicates setting {{ic|pinentry-mode loopback}} in {{ic|gpg.conf}} may break other usage, using the commandline option should be preferred if at all possible. [https://bugs.g10code.com/gnupg/issue1772]}}<br />
<br />
=== SSH agent ===<br />
<br />
''gpg-agent'' has OpenSSH agent emulation. If you already use the GnuPG suite, you might consider using its agent to also cache your SSH keys. Additionally, some users may prefer the PIN entry dialog GnuPG agent provides as part of its passphrase management.<br />
<br />
To start using GnuPG agent for your SSH keys, enable SSH support in the {{ic|~/.gnupg/gpg-agent.conf}} file:<br />
<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
enable-ssh-support<br />
}}<br />
<br />
Next, make sure that ''gpg-agent'' is always started. Use either the [[#Start gpg-agent with systemd user|systemd user service]] or add the following to your {{ic|.bashrc}} file:<br />
<br />
{{hc|~/.bashrc|<nowiki><br />
# Start the gpg-agent if not already running<br />
if ! pgrep -x -u "${USER}" gpg-agent >/dev/null 2>&1; then<br />
gpg-connect-agent /bye >/dev/null 2>&1<br />
fi<br />
</nowiki>}}<br />
<br />
Then set {{ic|SSH_AUTH_SOCK}} so that SSH will use ''gpg-agent'' instead of ''ssh-agent'':<br />
<br />
{{hc|~/.bashrc|<nowiki><br />
# Set SSH to use gpg-agent<br />
unset SSH_AGENT_PID<br />
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then<br />
export SSH_AUTH_SOCK="${HOME}/.gnupg/S.gpg-agent.ssh"<br />
fi<br />
</nowiki>}}<br />
<br />
Also set the GPG TTY and refresh the TTY in case user has switched into an X session. Example:<br />
<br />
{{Expansion|Not clear why this is necessary (even tha man page does not explain it).}}<br />
<br />
{{hc|~/.bashrc|<nowiki><br />
# Set GPG TTY<br />
export GPG_TTY=$(tty)<br />
<br />
# Refresh gpg-agent tty in case user switches into an X session<br />
gpg-connect-agent updatestartuptty /bye >/dev/null<br />
</nowiki>}}<br />
<br />
Once ''gpg-agent'' is running you can use ''ssh-add'' to approve keys, following the same steps as for [[SSH keys#ssh-agent|ssh-agent]]. The list of approved keys is stored in the {{ic|~/.gnupg/sshcontrol}} file. Once your key is approved, you will get a ''pinentry'' dialog every time your passphrase is needed. You can control passphrase caching in the {{ic|~/.gnupg/gpg-agent.conf}} file. The following example would have ''gpg-agent'' cache your keys for 3 hours:<br />
<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
default-cache-ttl-ssh 10800<br />
}}<br />
<br />
== Smartcards ==<br />
<br />
GnuPG uses ''scdaemon'' as an interface to your smartcard reader, please refer to the [[man page]] for details.<br />
<br />
=== GnuPG only setups ===<br />
<br />
{{Note| To allow scdaemon direct access to USB smarcard readers the optional dependency {{Pkg|libusb-compat}} have to be installed}}<br />
<br />
If you do not plan to use other cards but those based on GnuPG, you should check the {{Ic|reader-port}} parameter in {{ic|~/.gnupg/scdaemon.conf}}. The value '0' refers to the first available serial port reader and a value of '32768' (default) refers to the first USB reader.<br />
<br />
=== GnuPG with PSCD-Lite ===<br />
<br />
{{Note|{{Pkg|pcsclite}} and {{Pkg|ccid}} have to be installed, and the contained [[systemd#Using units|systemd]] service {{ic|pcscd.service}} has to be running, or the socket {{ic|pscd.socket}} has to be listening.}}<br />
<br />
PSCD-Lite is a daemon which handles access to smartcard (SCard API). If GnuPG's scdaemon fails to connect the smartcard directly (e.g. by using its integrated CCID support), it will fallback and try to find a smartcard using the PSCD-Lite driver.<br />
<br />
==== Always use PSCD-Light ====<br />
<br />
If you are using any smartcard with an opensc driver (e.g.: ID cards from some countries) you should pay some attention to GnuPG configuration. Out of the box you might receive a message like this when using {{Ic|gpg --card-status}}<br />
<br />
gpg: selecting openpgp failed: ec=6.108<br />
<br />
By default, scdaemon will try to connect directly to the device. This connection will fail if the reader is being used by another process. For example: the pcscd daemon used by OpenSC. To cope with this situation we should use the same underlying driver as opensc so they can work well together. In order to point scdaemon to use pcscd you should remove {{Ic|reader-port}} from {{ic|~/.gnupg/scdaemon.conf}}, specify the location to {{ic|libpcsclite.so}} library and disable ccid so we make sure that we use pcscd:<br />
<br />
{{hc|~/.gnupg/scdaemon.conf|<nowiki><br />
pcsc-driver /usr/lib/libpcsclite.so<br />
card-timeout 5<br />
disable-ccid<br />
</nowiki>}}<br />
<br />
Please check {{Ic|man scdaemon}} if you do not use OpenSC.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Different algorithm ===<br />
<br />
You may want to use stronger algorithms:<br />
<br />
{{hc|~/.gnupg/gpg.conf|<br />
...<br />
<br />
personal-digest-preferences SHA512<br />
cert-digest-algo SHA512<br />
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed<br />
personal-cipher-preferences TWOFISH CAMELLIA256 AES 3DES<br />
}}<br />
<br />
In the latest version of GnuPG, the default algorithms used are SHA256 and AES, both of which are secure enough for most people. However, if you are using a version of GnuPG older than 2.1, or if you want an even higher level of security, then you should follow the above step.<br />
<br />
=== Encrypt a password ===<br />
<br />
It can be useful to encrypt some password, so it will not be written in clear on a configuration file. A good example is your email password.<br />
<br />
First create a file with your password. You '''need''' to leave '''one''' empty line after the password, otherwise gpg will return an error message when evaluating the file.<br />
<br />
Then run:<br />
<br />
$ gpg -e -a -r ''<user-id>'' ''your_password_file''<br />
<br />
{{ic|-e}} is for encrypt, {{ic|-a}} for armor (ASCII output), {{ic|-r}} for recipient user ID.<br />
<br />
You will be left with a new {{ic|''your_password_file''.asc}} file.<br />
<br />
=== Revoking a key ===<br />
<br />
{{Warning|<br />
*Anybody having access to your revocation certificate can revoke your key, rendering it useless.<br />
*Key revocation should only be performed if your key is compromised or lost, or you forget your passphrase.}}<br />
<br />
Revocation certificates are automatically generated for newly generated keys, although one can be generated manually by the user later. These are located at {{ic|~/.gnupg/openpgp-revocs.d/}}. The filename of the certificate is the fingerprint of the key it will revoke.<br />
<br />
To revoke your key, simply import the revocation certificate:<br />
<br />
$ gpg --import ''<fingerprint>''.rev<br />
<br />
Now update the keyserver:<br />
<br />
$ gpg --keyserver subkeys.pgp.net --send ''<userid>''<br />
<br />
=== Change trust model ===<br />
<br />
By default GnuPG uses the [[Wikipedia::Web of Trust|Web of Trust]] as the trust model. You can change this to [[Wikipedia::Trust on First|Trust on First]] Use by adding {{ic|1=--trust-model=tofu}} when adding a key or adding this option to your GnuPG configuration file. More details are in [https://lists.gnupg.org/pipermail/gnupg-devel/2015-October/030341.html this email to the GnuPG list].<br />
<br />
=== Hide all recipient id's ===<br />
<br />
By default the recipient's key ID is in the encrypted message. This can be removed at encryption time for a recipient by using {{ic|hidden-recipient ''<user-id>''}}. To remove it for all recipients add {{ic|throw-keyids}} to your configuration file. This helps to hide the receivers of the message and is a limited countermeasure against traffic analysis. (Using a little social engineering anyone who is able to decrypt the message can check whether one of the other recipients is the one he suspects.) On the receiving side, it may slow down the decryption process because all available secret keys must be tried (''e.g.'' with {{ic|--try-secret-key ''<user-id>''}}).<br />
<br />
=== Using caff for keysigning parties ===<br />
<br />
To allow users to validate keys on the keyservers and in their keyrings (i.e. make sure they are from whom they claim to be), PGP/GPG uses he [[Wikipedia::Web of Trust|Web of Trust]]. Keysigning parties allow users to get together in physical location to validate keys. The [[Wikipedia:Zimmermann–Sassaman key-signing protocol|Zimmermann-Sassaman]] key-signing protocol is a way of making these very effective. [http://www.cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html Here] you will find a how-to article.<br />
<br />
For an easier process of signing keys and sending signatures to the owners after a keysigning party, you can use the tool ''caff''. It can be installed from the AUR with the package {{AUR|caff-svn}} or bundled together with other useful tools in the package {{AUR|signing-party-svn}}{{Broken package link|{{aur-mirror|signing-party-svn}}}}.<br />
Either way, there will be a lot of dependencies installing from the AUR. Alternatively you can install them from CPAN with<br />
cpanm Any::Moose<br />
cpanm GnuPG::Interface<br />
<br />
To send the signatures to their owners you need a working [[Wikipedia:Message transfer agent|MTA]]. If you do not have already one, install [[msmtp]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Not enough random bytes available ===<br />
When generating a key, gpg can run into this error:<br />
Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy!<br />
To check the available entropy, check the kernel parameters:<br />
cat /proc/sys/kernel/random/entropy_avail<br />
A healthy Linux system with a lot of entropy available will have return close to the full 4,096 bits of entropy. If the value returned is less than 200, the system is running low on entropy. <br />
<br />
To solve it, remember you do not often need to create keys and best just do what the message suggests (e.g. create disk activity, move the mouse, edit the wiki - all will create entropy). If that does not help, check which service is using up the entropy and consider stopping it for the time. If that is no alternative, see [[Random number generation#Faster alternatives]].<br />
<br />
=== su ===<br />
<br />
When using {{Ic|pinentry}}, you must have the proper permissions of the terminal device (e.g. {{Ic|/dev/tty1}}) in use. However, with ''su'' (or ''sudo''), the ownership stays with the original user, not the new one. This means that pinentry will fail, even as root. The fix is to change the permissions of the device at some point before the use of pinentry (i.e. using gpg with an agent). If doing gpg as root, simply change the ownership to root right before using gpg:<br />
<br />
chown root /dev/ttyN # where N is the current tty<br />
<br />
and then change it back after using gpg the first time. The equivalent is likely to be true with {{Ic|/dev/pts/}}.<br />
<br />
{{Note|The owner of tty ''must'' match with the user for which pinentry is running. Being part of the group {{Ic|tty}} '''is not''' enough.}}<br />
<br />
=== Agent complains end of file ===<br />
<br />
The default pinentry program is pinentry-gtk-2, which needs a DBus session bus to run properly. See [[General troubleshooting#Session permissions]] for details.<br />
<br />
Alternatively, you can use {{ic|pinentry-qt}}. See [[#pinentry]].<br />
<br />
=== KGpg configuration permissions ===<br />
<br />
There have been issues with {{Pkg|kdeutils-kgpg}} being able to access the {{ic|~/.gnupg/}} options. One issue might be a result of a deprecated ''options'' file, see the [https://bugs.kde.org/show_bug.cgi?id=290221 bug] report.<br />
<br />
Another user reported that ''KGpg'' failed to start until the {{ic|~/.gnupg}} folder is set to {{ic|drwxr-xr-x}} permissions. If you require this work-around, ensure that the directory contents retain {{ic|-rw-------}} permissions! Further, report it as a bug to the [https://bugs.kde.org/buglist.cgi?quicksearch=kgpg developers].<br />
<br />
=== Conflicts between gnome-keyring and gpg-agent ===<br />
<br />
{{Accuracy|See [[#GPG_AGENT_INFO]]}}<br />
<br />
While the Gnome keyring implements a GPG agent component, as of GnuPG version 2.1, GnuPG ignores the {{ic|GPG_AGENT_INFO}} environment variable, so that Gnome keyring can no longer be used as a GPG agent.<br />
<br />
However, since version 0.9.6 the package {{Pkg|pinentry}} provides the {{Ic|pinentry-gnome3}} program. You may set the following option in your {{Ic|gpg-agent.conf}} file<br />
pinentry-program /usr/bin/pinentry-gnome3<br />
in order to make use of that pinentry program.<br />
<br />
Since version 0.9.2 all pinentry programs can be configured to optionally save a passphrase with libsecret. For example, when the user is asked for a passphrase via {{Ic|pinentry-gnome3}}, a checkbox is shown whether to save the passphrase using a password manager. Unfortunately, the package {{Pkg|pinentry}} does not have this feature enabled (see {{Bug|46059}} for the reasons). You may use {{AUR|pinentry-libsecret}} as a replacement for it, which has support for libsecret enabled.<br />
<br />
=== mutt and gpg ===<br />
<br />
To be asked for your GnuPG password only once per session as of GnuPG 2.1, see [https://bbs.archlinux.org/viewtopic.php?pid=1490821#p1490821 this forum thread].<br />
<br />
=== "Lost" keys, upgrading to gnupg version 2.1 ===<br />
<br />
When {{ic|gpg --list-keys}} fails to show keys that used to be there, and applications complain about missing or invalid keys, some keys may not have been migrated to the new format.<br />
<br />
Please read [http://jo-ke.name/wp/?p=111 GnuPG invalid packet workaround]. Basically, it says that there is a bug with keys in the old {{ic|pubring.gpg}} and {{ic|secring.gpg}} files, which have now been superseded by the new {{ic|pubring.kbx}} file and the {{ic|private-keys-v1.d/}} subdirectory and files. Your missing keys can be recovered with the following commnads:<br />
<br />
$ cd<br />
$ cp -r .gnupg gnupgOLD<br />
$ gpg --export-ownertrust > otrust.txt<br />
$ gpg --import .gnupg/pubring.gpg<br />
$ gpg --import-ownertrust otrust.txt<br />
$ gpg --list-keys<br />
<br />
=== gpg hanged for all keyservers (when trying to receive keys) ===<br />
<br />
If gpg hanged with a certain keyserver when trying to receive keys, you might need to kill dirmngr in order to get access to other keyservers which are actually working, otherwise it might keeping hanging for all of them.<br />
<br />
=== Smartcard not detected ===<br />
<br />
Your user might not have the permission to access the smartcard which results in a {{ic|card error}} to be thrown, even though the card is correctly set up and inserted.<br />
<br />
One possible solution is to add a new group {{ic|scard}} including the users who need access to the smartcard.<br />
<br />
Then use an [[Udev#Writing_udev_rules|udev]] rule, similar to the following:<br />
{{hc|/etc/udev/rules.d/71-gnupg-ccid.rules|<nowiki><br />
ACTION=="add", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="1050", ENV{ID_MODEL_ID}=="0116|0111", MODE="660", GROUP="scard"<br />
</nowiki>}}<br />
One needs to adapt VENDOR and MODEL according to the {{ic|lsusb}} output, the above example is for a YubikeyNEO.<br />
<br />
== See also ==<br />
<br />
* [https://gnupg.org/ GNU Privacy Guard Homepage]<br />
* [https://fedoraproject.org/wiki/Creating_GPG_Keys Creating GPG Keys (Fedora)]<br />
* [https://wiki.debian.org/Subkeys OpenPGP subkeys in Debian]<br />
* [http://blog.sanctum.geek.nz/series/linux-crypto/ A more comprehensive gpg Tutorial]<br />
* [https://help.riseup.net/en/security/message-security/openpgp/gpg-best-practices gpg.conf recommendations and best practices]<br />
* [https://github.com/ioerror/torbirdy/blob/master/gpg.conf Torbirdy gpg.conf]<br />
* [https://www.reddit.com/r/GPGpractice/ /r/GPGpractice - a subreddit to practice using GnuPG.]</div>Ritkahttps://wiki.archlinux.org/index.php?title=GnuPG&diff=434683GnuPG2016-05-11T18:35:31Z<p>Ritka: /* Encrypt and decrypt */ added 'by using your own user-id as recipient' to the Note-Box. to explain how you would use gpg to encrypt files for yourself.</p>
<hr />
<div>[[Category:Encryption]]<br />
[[es:GnuPG]]<br />
[[ja:GnuPG]]<br />
[[ru:GnuPG]]<br />
[[zh-cn:GnuPG]]<br />
{{Related articles start}}<br />
{{Related|pacman/Package signing}}<br />
{{Related|Disk encryption}}<br />
{{Related|List of applications/Security#Encryption, signing, steganography}}<br />
{{Related articles end}}<br />
<br />
According to the [http://www.gnupg.org official website]:<br />
<br />
:GnuPG is a complete and free implementation of the OpenPGP standard as defined by RFC4880 (also known as [[Wikipedia:PGP|PGP]]). GnuPG allows to encrypt and sign your data and communication, features a versatile key management system as well as access modules for all kinds of public key directories. GnuPG, also known as GPG, is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries are available. Version 2 of GnuPG also provides support for S/MIME and Secure Shell (ssh).<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|gnupg}} package.<br />
<br />
This will also install {{Pkg|pinentry}}, a collection of simple PIN or passphrase entry dialogs which GnuPG uses for passphrase entry. Which ''pinentry'' dialog is used is determined by the symbolic link {{ic|/usr/bin/pinentry}}, which by default points to {{ic|/usr/bin/pinentry-gtk-2}}.<br />
<br />
If you want to use a graphical frontend or program that integrates with GnuPG, see [[List of applications/Security#Encryption, signing, steganography]].<br />
<br />
== Configuration ==<br />
<br />
=== Directory location ===<br />
{{ic|$GNUPGHOME}} is used by GnuPG to point to the directory where its configuration files are stored. By default {{ic|$GNUPGHOME}} is not set and your {{ic|$HOME}} is used instead; thus, you will find a {{ic|~/.gnupg}} directory right after installation. <br />
<br />
To change the default location, either run gpg this way {{ic|$ gpg --homedir ''path/to/file''}} or set {{ic|GNUPGHOME}} in one of your regular [[startup files]].<br />
<br />
=== Configuration files ===<br />
<br />
The default configuration files are {{ic|~/.gnupg/gpg.conf}} and {{ic|~/.gnupg/dirmngr.conf}}. <br />
<br />
By default, the gnupg directory has its [[permissions]] set to {{ic|700}} and the files it contains have their permissions set to {{ic|600}}. Only the owner of the directory has permission to read, write, and access the files. This is for security purposes and should not be changed. In case this directory or any file inside it does not follow this security measure, you will get warnings about unsafe file and home directory permissions.<br />
<br />
Append to these files any long options you want. Do not write the two dashes, but simply the name of the option and required arguments. You will find skeleton files in {{ic|/usr/share/gnupg}}. These files are copied to {{ic|~/.gnupg}} the first time gpg is run if they do not exist there. Other examples are found in [[#See also]].<br />
<br />
Additionally, [[pacman]] uses a different set of configuration files for package signature verification. See [[Pacman/Package signing]] for details.<br />
<br />
=== Default options for new users ===<br />
<br />
If you want to setup some default options for new users, put configuration files in {{ic|/etc/skel/.gnupg/}}. When the new user is added in system, files from here will be copied to its GnuPG home directory. There is also a simple script called ''addgnupghome'' which you can use to create new GnuPG home directories for existing users:<br />
<br />
# addgnupghome user1 user2<br />
<br />
This will add the respective {{ic|/home/user1/.gnupg}} and {{ic|/home/user2/.gnupg}} and copy the files from the skeleton directory to it. Users with existing GnuPG home directory are simply skipped.<br />
<br />
== Usage ==<br />
<br />
{{Note|Whenever a ''{{ic|<user-id>}}'' is required in a command, it can be specified with your key ID, fingerprint, a part of your name or email address, etc. GnuPG is flexible on this.<br />
}}<br />
<br />
=== Create key pair ===<br />
<br />
Generate a key pair by typing in a terminal:<br />
<br />
$ gpg --full-gen-key<br />
<br />
{{Tip|Use the {{ic|--expert}} option for getting alternative ciphers like [[wikipedia:Elliptic_curve_cryptography|ECC]].}}<br />
<br />
The command will prompt for answers to several questions. For general use most people will want: <br />
<br />
* the RSA (sign only) and a RSA (encrypt only) key.<br />
* a keysize of the default value (2048). A larger keysize of 4096 "gives us almost nothing, while costing us quite a lot"[https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096].<br />
* an expiration date. A period of a year is good enough for the average user. This way even if access is lost to the keyring, it will allow others to know that it is no longer valid. Later, if necessary, the expiration date can be extended without having to re-issue a new key.<br />
* your name and email address. You can add multiple identities to the same key later (''e.g.'', if you have multiple email addresses you want to associate with this key).<br />
* ''no'' optional comment. Since the semantics of the comment field are [https://lists.gnupg.org/pipermail/gnupg-devel/2015-July/030150.html not well-defined], it has limited value for identification.<br />
* [[Security#Choosing_secure_passwords|a secure passphrase]].<br />
<br />
{{Note|The name and email address you enter here will be seen by anybody who imports your key.}}<br />
<br />
=== List keys ===<br />
<br />
To list keys in your public key ring:<br />
<br />
$ gpg --list-keys<br />
<br />
To list keys in your secret key ring:<br />
<br />
$ gpg --list-secret-keys<br />
<br />
=== Export your public key ===<br />
<br />
In order for others to send encrypted messages to you, they need your public key.<br />
<br />
To generate an ASCII version of your public key (''e.g.'' to distribute it by e-mail):<br />
<br />
$ gpg --armor --output ''public.key'' --export ''<user-id>''<br />
<br />
Alternatively, or in addition, you can [[#Use a keyserver]] to share your key. <br />
<br />
{{Tip|Add {{ic|--no-emit-version}} to avoid printing the version number, or add the corresponding setting to your configuration file.}}<br />
<br />
=== Import a key ===<br />
<br />
In order to encrypt messages to others, as well as verify their signatures, you need their public key. To import a public key with file name {{ic|''public.key''}} to your public key ring:<br />
<br />
$ gpg --import ''public.key''<br />
<br />
Alternatively, [[#Use a keyserver]] to find a public key.<br />
<br />
=== Use a keyserver ===<br />
<br />
You can register your key with a public PGP key server, so that others can retrieve your key without having to contact you directly:<br />
<br />
$ gpg --send-keys ''<key-id>''<br />
<br />
To find out details of a key on the keyserver, without importing it, do:<br />
<br />
$ gpg --search-keys ''<key-id>''<br />
<br />
To import a key from a key server:<br />
<br />
$ gpg --recv-keys ''<key-id>''<br />
<br />
{{Warning|Anyone can send keys to a keyserver, so you should not trust that the key you download actually belongs to the individual listed. You should verify the authenticity of the retrieved public key by comparing its fingerprint with one that the owner published on an independent source, such as their own blog or website, or contacting them by email, over the phone or in person. Using multiple authentication sources will increase the level of trust you can give to the downloaded key. See [[Wikipedia:Public key fingerprint]] for more information.}}<br />
<br />
{{Tip|<br />
* Adding {{ic|keyserver-options auto-key-retrieve}} to {{ic|gpg.conf}} will automatically fetch keys from the key server as needed.<br />
* An alternative key server is {{ic|pool.sks-keyservers.net}} and can be specified with {{ic|keyserver}} in {{ic|dirmngr.conf}}.; see also [[wikipedia:Key server (cryptographic)#Keyserver examples]].<br />
* You can connect to the keyserver over [[Tor]] using {{ic|--use-tor}}. {{ic|hkp://jijrk5u4osbsr34t5.onion}} is the onion address for the sks-keyservers pool. [https://gnupg.org/blog/20151224-gnupg-in-november-and-december.html See this GnuPG blog post] for more information.<br />
* You can connect to a keyserver using a proxy by setting the {{ic|http_proxy}} environment variable and setting {{ic|honor-http-proxy}} in {{ic|dirmngr.conf}}. Alternatively, set {{ic|http-proxy ''host[:port]''}} in {{ic|dirmngr.conf}}, overriding the {{ic|http_proxy}} environment variable.}}<br />
<br />
=== Encrypt and decrypt ===<br />
<br />
gpg's main usage is public-key cryptography (see [[Wikipedia:Public-key cryptography]]). That means, you usually use a users public key to encrypt files and you use your private key to decrypt them.<br />
<br />
To encrypt a file with the name ''doc'', use:<br />
<br />
$ gpg -e -r ''<user-id>'' ''doc''<br />
<br />
where ''<user-id>'' should refer to the user who shall be able to decrypt the file. Note that you need to import the users public key before.<br />
<br />
{{Tip|<br />
* Add {{ic|--armor}} to encrypt a file using ASCII armor (suitable for copying and pasting a message in text format)<br />
* Use {{ic|-R ''<user-id>''}} or {{ic|--hidden-recipient ''<user-id>''}} instead of {{ic|-r}} to not put the recipient key IDs in the encrypted message. This helps to hide the receivers of the message and is a limited countermeasure against traffic analysis.<br />
* Add {{ic|--no-emit-version}} to avoid printing the version number, or add the corresponding setting to your configuration file.}}<br />
<br />
{{Note|You can use gnupg to encrypt your sensitive documents by using your own user-id as recipient, but only individual files at a time. If you want to encrypt directories or a whole file-system you should consider using [[TrueCrypt]] or [[EncFS]], though you can always tarball various files and then encrypt them.}}<br />
<br />
To decrypt a file encrypted with your public key, use:<br />
<br />
$ gpg --decrypt ''doc.asc''<br />
<br />
You will be prompted to enter your passphrase.<br />
<br />
== Key maintenance ==<br />
<br />
=== Backup your private key ===<br />
<br />
To backup your private key do the following:<br />
<br />
$ gpg --export-secret-keys --armor ''<user-id>'' > ''privkey.asc''<br />
<br />
Note that ''gpg'' release 2.1 changed default behaviour so that the above command enforces a passphrase protection, even if you deliberately chose not to use one on key creation. This is because otherwise anyone who gains access to the above exported file would be able to encrypt and sign documents as if they were you ''without'' needing to know your passphrase. <br />
<br />
{{Warning|The passphrase is usually the weakest link in protecting your secret key. Place the private key in a safe place on a different system/device, such as a locked container or encrypted drive. It is the only safety you have to regain control to your keyring in case of, for example, a drive failure, theft or worse.}}<br />
<br />
=== Edit your key ===<br />
<br />
Running the {{ic|gpg --edit-key ''<user-id>''}} command will present a menu which enables you to do most of your key management related tasks.<br />
<br />
Some useful commands in the edit key sub menu:<br />
> passwd # change the passphrase<br />
> clean # compact any user ID that is no longer usable (e.g revoked or expired)<br />
> revkey # revoke a key<br />
> addkey # add a subkey to this key<br />
> expire # change the key expiration time<br />
<br />
Type {{ic|help}} in the edit key sub menu for more commands.<br />
<br />
{{Tip|If you have multiple email accounts you can add each one of them as an identity, using {{ic|adduid}} command. You can then set your favourite one as {{ic|primary}}.}}<br />
<br />
=== Exporting subkey ===<br />
<br />
If you plan to use the same key across multiple devices, you may want to strip out your master key and only keep the bare minimum encryption subkey on less secure systems.<br />
<br />
First, find out which subkey you want to export.<br />
<br />
$ gpg -K<br />
<br />
Select only that subkey to export.<br />
<br />
$ gpg -a --export-secret-subkeys [subkey id]! > /tmp/subkey.gpg<br />
<br />
{{Warning|If you forget to add the !, all of your subkeys will be exported.}}<br />
<br />
At this point you could stop, but it is most likely a good idea to change the passphrase as well. Import the key into a temporary folder. <br />
<br />
$ gpg --homedir /tmp/gpg --import /tmp/subkey.gpg<br />
$ gpg --homedir /tmp/gpg --edit-key ''<user-id>''<br />
> passwd<br />
> save<br />
$ gpg --homedir /tmp/gpg -a --export-secret-subkeys [subkey id]! > /tmp/subkey.altpass.gpg<br />
<br />
{{Note|You will get a warning that the master key was not available and the password was not changed, but that can safely be ignored as the subkey password was.}}<br />
<br />
At this point, you can now use {{ic|/tmp/subkey.altpass.gpg}} on your other devices.<br />
<br />
=== Rotating subkeys ===<br />
<br />
{{Warning|'''Never''' delete your expired or revoked subkeys unless you have a good reason. Doing so will cause you to lose the ability to decrypt files encrypted with the old subkey. Please '''only''' delete expired or revoked keys from other users to clean your keyring.}}<br />
<br />
If you have set your subkeys to expire after a set time, you can create new ones. Do this a few weeks in advance to allow others to update their keyring.<br />
<br />
{{Note|You do not need to create a new key simply because it is expired. You can extend the expiration date.}}<br />
<br />
Create new subkey (repeat for both signing and encrypting key)<br />
<br />
$ gpg --edit-key ''<user-id>''<br />
> addkey<br />
<br />
And answer the following questions it asks (see previous section for suggested settings).<br />
<br />
Save changes<br />
<br />
> save<br />
<br />
Update it to a keyserver.<br />
<br />
$ gpg --keyserver pgp.mit.edu --send-keys ''<user-id>''<br />
<br />
{{Note|Revoking expired subkeys is unnecessary and arguably bad form. If you are constantly revoking keys, it may cause others to lack confidence in you.}}<br />
<br />
== Signatures ==<br />
<br />
Signatures certify and timestamp documents. If the document is modified, verification of the signature will fail. Unlike encryption which uses public keys to encrypt a document, signatures are created with the user's private key. The recipient of a signed document then verifies the signature using the sender's public key.<br />
<br />
=== Sign a file ===<br />
<br />
To sign a file use the {{ic|--sign}} or {{ic|-s}} flag:<br />
<br />
$ gpg --output ''doc.sig'' --sign ''doc''<br />
<br />
The above also encrypts the file and stores it in binary format.<br />
<br />
=== Clearsign a file or message ===<br />
<br />
To sign a file without compressing it into binary format use:<br />
<br />
$ gpg --clearsign ''doc''<br />
<br />
This wraps the document into an ASCII-armored signature, but does not modify the document.<br />
<br />
=== Make a detached signature ===<br />
<br />
To create a separate signature file to be distributed separately from the document or file itself, use the {{ic|--detach-sig}} flag:<br />
<br />
$ gpg --output ''doc.sig'' --detach-sig ''doc''<br />
<br />
This method is often used in distributing software projects to allow users to verify that the program has not been modified by a third part.<br />
<br />
=== Verify a signature ===<br />
<br />
To verify a signature use the {{ic|--verify}} flag:<br />
<br />
$ gpg --verify ''doc.sig''<br />
<br />
where {{ic|''doc.sig''}} is the signature you wish to verify.<br />
<br />
To verify and decrypt a file at the same time, use the {{ic|--decrypt}} flag as you normally would in decrypting a file.<br />
<br />
If you are verifying a detached signature, both the file and the signature must be present when verifying. For example, to verify Arch Linux's latest iso you would do:<br />
<br />
$ gpg --verify ''archlinux-<version>-dual.iso.sig''<br />
<br />
where {{ic|''archlinux-<version>-dual.iso''}} must be located in the same directory.<br />
<br />
== gpg-agent ==<br />
<br />
''gpg-agent'' is mostly used as daemon to request and cache the password for the keychain. This is useful if GnuPG is used from an external program like a mail client.<br />
<br />
Starting with GnuPG 2.1.0 the use of ''gpg-agent'' is required. ''gpg-agent'' is started on-demand by the GnuPG tools, so there is usually no reason to start it manually.<br />
<br />
=== Configuration ===<br />
<br />
gpg-agent can be configured via {{ic|~/.gnupg/gpg-agent.conf}} file. The configuration options are listed in {{ic|man gpg-agent}}. For example you can change cache ttl for unused keys:<br />
<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
default-cache-ttl 3600<br />
}}<br />
<br />
{{Tip|To cache your passphrase for the whole session, please run the following command:<br />
$ /usr/lib/gnupg/gpg-preset-passphrase --preset XXXXXX<br />
<br />
where XXXX is the keygrip. You can get its value when running {{ic|gpg --with-keygrip -K}}. Passphrase will be stored until {{ic|gpg-agent}} is restarted. If you set up {{ic|default-cache-ttl}} value, it will take precedence.<br />
}}<br />
<br />
=== Reload the agent ===<br />
<br />
After changing the configuration, reload the agent using ''gpg-connect-agent'':<br />
<br />
$ gpg-connect-agent reloadagent /bye<br />
<br />
The command should print {{ic|OK}}.<br />
<br />
=== pinentry ===<br />
<br />
Finally, the agent needs to know how to ask the user for the password. This can be set in the gpg-agent configuration file.<br />
<br />
The default uses a gtk dialog. There are other options - see {{ic|info pinentry}}. To change the dialog implementation set {{ic|pinentry-program}} configuration option:<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
<br />
# PIN entry program<br />
# pinentry-program /usr/bin/pinentry-curses<br />
# pinentry-program /usr/bin/pinentry-qt<br />
# pinentry-program /usr/bin/pinentry-kwallet<br />
<br />
pinentry-program /usr/bin/pinentry-gtk-2<br />
}}<br />
<br />
{{Tip|For using {{ic|/usr/bin/pinentry-kwallet}} you have to install the {{Pkg|kwalletcli}} package.}}<br />
<br />
After making this change, reload the gpg-agent.<br />
<br />
=== Start gpg-agent with systemd user ===<br />
<br />
It is possible to use the [[Systemd/User]] facilities to start the agent.<br />
<br />
Create a systemd unit file:<br />
<br />
{{hc|~/.config/systemd/user/gpg-agent.service|2=<br />
[Unit]<br />
Description=GnuPG private key agent<br />
IgnoreOnIsolate=true<br />
<br />
[Service]<br />
Type=forking<br />
ExecStart=/usr/bin/gpg-agent --daemon<br />
Restart=on-abort<br />
<br />
[Install]<br />
WantedBy=default.target<br />
}}<br />
<br />
{{Note|If you use non-default value for the [[#GNUPGHOME]] environment variable, you need to pass it to the service. See [[systemd/User#Environment variables]] for details.}}<br />
<br />
=== Unattended passphrase ===<br />
<br />
Starting with GnuPG 2.1.0 the use of gpg-agent and pinentry is required, which may break backwards compatibility for passphrases piped in from STDIN using the {{ic|--passphrase-fd 0}} commandline option. In order to have the same type of functionality as the older releases two things must be done:<br />
<br />
First, edit the gpg-agent configuration to allow ''loopback'' pinentry mode:<br />
<br />
{{hc|1=~/.gnupg/gpg-agent.conf|2=<br />
allow-loopback-pinentry<br />
}}<br />
<br />
Restart the gpg-agent process if it is running to let the change take effect.<br />
<br />
Second, either the application needs to be updated to include a commandline parameter to use loopback mode like so:<br />
<br />
$ gpg --pinentry-mode loopback ...<br />
<br />
...or if this is not possible, add the option to the configuration:<br />
<br />
{{hc|1=~/.gnupg/gpg.conf|2=<br />
pinentry-mode loopback<br />
}}<br />
<br />
{{Note|The upstream author indicates setting {{ic|pinentry-mode loopback}} in {{ic|gpg.conf}} may break other usage, using the commandline option should be preferred if at all possible. [https://bugs.g10code.com/gnupg/issue1772]}}<br />
<br />
=== SSH agent ===<br />
<br />
''gpg-agent'' has OpenSSH agent emulation. If you already use the GnuPG suite, you might consider using its agent to also cache your SSH keys. Additionally, some users may prefer the PIN entry dialog GnuPG agent provides as part of its passphrase management.<br />
<br />
To start using GnuPG agent for your SSH keys, enable SSH support in the {{ic|~/.gnupg/gpg-agent.conf}} file:<br />
<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
enable-ssh-support<br />
}}<br />
<br />
Next, make sure that ''gpg-agent'' is always started. Use either the [[#Start gpg-agent with systemd user|systemd user service]] or add the following to your {{ic|.bashrc}} file:<br />
<br />
{{hc|~/.bashrc|<nowiki><br />
# Start the gpg-agent if not already running<br />
if ! pgrep -x -u "${USER}" gpg-agent >/dev/null 2>&1; then<br />
gpg-connect-agent /bye >/dev/null 2>&1<br />
fi<br />
</nowiki>}}<br />
<br />
Then set {{ic|SSH_AUTH_SOCK}} so that SSH will use ''gpg-agent'' instead of ''ssh-agent'':<br />
<br />
{{hc|~/.bashrc|<nowiki><br />
# Set SSH to use gpg-agent<br />
unset SSH_AGENT_PID<br />
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then<br />
export SSH_AUTH_SOCK="${HOME}/.gnupg/S.gpg-agent.ssh"<br />
fi<br />
</nowiki>}}<br />
<br />
Also set the GPG TTY and refresh the TTY in case user has switched into an X session. Example:<br />
<br />
{{Expansion|Not clear why this is necessary (even tha man page does not explain it).}}<br />
<br />
{{hc|~/.bashrc|<nowiki><br />
# Set GPG TTY<br />
export GPG_TTY=$(tty)<br />
<br />
# Refresh gpg-agent tty in case user switches into an X session<br />
gpg-connect-agent updatestartuptty /bye >/dev/null<br />
</nowiki>}}<br />
<br />
Once ''gpg-agent'' is running you can use ''ssh-add'' to approve keys, following the same steps as for [[SSH keys#ssh-agent|ssh-agent]]. The list of approved keys is stored in the {{ic|~/.gnupg/sshcontrol}} file. Once your key is approved, you will get a ''pinentry'' dialog every time your passphrase is needed. You can control passphrase caching in the {{ic|~/.gnupg/gpg-agent.conf}} file. The following example would have ''gpg-agent'' cache your keys for 3 hours:<br />
<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
default-cache-ttl-ssh 10800<br />
}}<br />
<br />
== Smartcards ==<br />
<br />
GnuPG uses ''scdaemon'' as an interface to your smartcard reader, please refer to the [[man page]] for details.<br />
<br />
=== GnuPG only setups ===<br />
<br />
{{Note| To allow scdaemon direct access to USB smarcard readers the optional dependency {{Pkg|libusb-compat}} have to be installed}}<br />
<br />
If you do not plan to use other cards but those based on GnuPG, you should check the {{Ic|reader-port}} parameter in {{ic|~/.gnupg/scdaemon.conf}}. The value '0' refers to the first available serial port reader and a value of '32768' (default) refers to the first USB reader.<br />
<br />
=== GnuPG with PSCD-Lite ===<br />
<br />
{{Note|{{Pkg|pcsclite}} and {{Pkg|ccid}} have to be installed, and the contained [[systemd#Using units|systemd]] service {{ic|pcscd.service}} has to be running, or the socket {{ic|pscd.socket}} has to be listening.}}<br />
<br />
PSCD-Lite is a daemon which handles access to smartcard (SCard API). If GnuPG's scdaemon fails to connect the smartcard directly (e.g. by using its integrated CCID support), it will fallback and try to find a smartcard using the PSCD-Lite driver.<br />
<br />
==== Always use PSCD-Light ====<br />
<br />
If you are using any smartcard with an opensc driver (e.g.: ID cards from some countries) you should pay some attention to GnuPG configuration. Out of the box you might receive a message like this when using {{Ic|gpg --card-status}}<br />
<br />
gpg: selecting openpgp failed: ec=6.108<br />
<br />
By default, scdaemon will try to connect directly to the device. This connection will fail if the reader is being used by another process. For example: the pcscd daemon used by OpenSC. To cope with this situation we should use the same underlying driver as opensc so they can work well together. In order to point scdaemon to use pcscd you should remove {{Ic|reader-port}} from {{ic|~/.gnupg/scdaemon.conf}}, specify the location to {{ic|libpcsclite.so}} library and disable ccid so we make sure that we use pcscd:<br />
<br />
{{hc|~/.gnupg/scdaemon.conf|<nowiki><br />
pcsc-driver /usr/lib/libpcsclite.so<br />
card-timeout 5<br />
disable-ccid<br />
</nowiki>}}<br />
<br />
Please check {{Ic|man scdaemon}} if you do not use OpenSC.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Different algorithm ===<br />
<br />
You may want to use stronger algorithms:<br />
<br />
{{hc|~/.gnupg/gpg.conf|<br />
...<br />
<br />
personal-digest-preferences SHA512<br />
cert-digest-algo SHA512<br />
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed<br />
personal-cipher-preferences TWOFISH CAMELLIA256 AES 3DES<br />
}}<br />
<br />
In the latest version of GnuPG, the default algorithms used are SHA256 and AES, both of which are secure enough for most people. However, if you are using a version of GnuPG older than 2.1, or if you want an even higher level of security, then you should follow the above step.<br />
<br />
=== Encrypt a password ===<br />
<br />
It can be useful to encrypt some password, so it will not be written in clear on a configuration file. A good example is your email password.<br />
<br />
First create a file with your password. You '''need''' to leave '''one''' empty line after the password, otherwise gpg will return an error message when evaluating the file.<br />
<br />
Then run:<br />
<br />
$ gpg -e -a -r ''<user-id>'' ''your_password_file''<br />
<br />
{{ic|-e}} is for encrypt, {{ic|-a}} for armor (ASCII output), {{ic|-r}} for recipient user ID.<br />
<br />
You will be left with a new {{ic|''your_password_file''.asc}} file.<br />
<br />
=== Revoking a key ===<br />
<br />
{{Warning|<br />
*Anybody having access to your revocation certificate can revoke your key, rendering it useless.<br />
*Key revocation should only be performed if your key is compromised or lost, or you forget your passphrase.}}<br />
<br />
Revocation certificates are automatically generated for newly generated keys, although one can be generated manually by the user later. These are located at {{ic|~/.gnupg/openpgp-revocs.d/}}. The filename of the certificate is the fingerprint of the key it will revoke.<br />
<br />
To revoke your key, simply import the revocation certificate:<br />
<br />
$ gpg --import ''<fingerprint>''.rev<br />
<br />
Now update the keyserver:<br />
<br />
$ gpg --keyserver subkeys.pgp.net --send ''<userid>''<br />
<br />
=== Change trust model ===<br />
<br />
By default GnuPG uses the [[Wikipedia::Web of Trust|Web of Trust]] as the trust model. You can change this to [[Wikipedia::Trust on First|Trust on First]] Use by adding {{ic|1=--trust-model=tofu}} when adding a key or adding this option to your GnuPG configuration file. More details are in [https://lists.gnupg.org/pipermail/gnupg-devel/2015-October/030341.html this email to the GnuPG list].<br />
<br />
=== Hide all recipient id's ===<br />
<br />
By default the recipient's key ID is in the encrypted message. This can be removed at encryption time for a recipient by using {{ic|hidden-recipient ''<user-id>''}}. To remove it for all recipients add {{ic|throw-keyids}} to your configuration file. This helps to hide the receivers of the message and is a limited countermeasure against traffic analysis. (Using a little social engineering anyone who is able to decrypt the message can check whether one of the other recipients is the one he suspects.) On the receiving side, it may slow down the decryption process because all available secret keys must be tried (''e.g.'' with {{ic|--try-secret-key ''<user-id>''}}).<br />
<br />
=== Using caff for keysigning parties ===<br />
<br />
To allow users to validate keys on the keyservers and in their keyrings (i.e. make sure they are from whom they claim to be), PGP/GPG uses he [[Wikipedia::Web of Trust|Web of Trust]]. Keysigning parties allow users to get together in physical location to validate keys. The [[Wikipedia:Zimmermann–Sassaman key-signing protocol|Zimmermann-Sassaman]] key-signing protocol is a way of making these very effective. [http://www.cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html Here] you will find a how-to article.<br />
<br />
For an easier process of signing keys and sending signatures to the owners after a keysigning party, you can use the tool ''caff''. It can be installed from the AUR with the package {{AUR|caff-svn}} or bundled together with other useful tools in the package {{AUR|signing-party-svn}}{{Broken package link|{{aur-mirror|signing-party-svn}}}}.<br />
Either way, there will be a lot of dependencies installing from the AUR. Alternatively you can install them from CPAN with<br />
cpanm Any::Moose<br />
cpanm GnuPG::Interface<br />
<br />
To send the signatures to their owners you need a working [[Wikipedia:Message transfer agent|MTA]]. If you do not have already one, install [[msmtp]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Not enough random bytes available ===<br />
When generating a key, gpg can run into this error:<br />
Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy!<br />
To check the available entropy, check the kernel parameters:<br />
cat /proc/sys/kernel/random/entropy_avail<br />
A healthy Linux system with a lot of entropy available will have return close to the full 4,096 bits of entropy. If the value returned is less than 200, the system is running low on entropy. <br />
<br />
To solve it, remember you do not often need to create keys and best just do what the message suggests (e.g. create disk activity, move the mouse, edit the wiki - all will create entropy). If that does not help, check which service is using up the entropy and consider stopping it for the time. If that is no alternative, see [[Random number generation#Faster alternatives]].<br />
<br />
=== su ===<br />
<br />
When using {{Ic|pinentry}}, you must have the proper permissions of the terminal device (e.g. {{Ic|/dev/tty1}}) in use. However, with ''su'' (or ''sudo''), the ownership stays with the original user, not the new one. This means that pinentry will fail, even as root. The fix is to change the permissions of the device at some point before the use of pinentry (i.e. using gpg with an agent). If doing gpg as root, simply change the ownership to root right before using gpg:<br />
<br />
chown root /dev/ttyN # where N is the current tty<br />
<br />
and then change it back after using gpg the first time. The equivalent is likely to be true with {{Ic|/dev/pts/}}.<br />
<br />
{{Note|The owner of tty ''must'' match with the user for which pinentry is running. Being part of the group {{Ic|tty}} '''is not''' enough.}}<br />
<br />
=== Agent complains end of file ===<br />
<br />
The default pinentry program is pinentry-gtk-2, which needs a DBus session bus to run properly. See [[General troubleshooting#Session permissions]] for details.<br />
<br />
Alternatively, you can use {{ic|pinentry-qt}}. See [[#pinentry]].<br />
<br />
=== KGpg configuration permissions ===<br />
<br />
There have been issues with {{Pkg|kdeutils-kgpg}} being able to access the {{ic|~/.gnupg/}} options. One issue might be a result of a deprecated ''options'' file, see the [https://bugs.kde.org/show_bug.cgi?id=290221 bug] report.<br />
<br />
Another user reported that ''KGpg'' failed to start until the {{ic|~/.gnupg}} folder is set to {{ic|drwxr-xr-x}} permissions. If you require this work-around, ensure that the directory contents retain {{ic|-rw-------}} permissions! Further, report it as a bug to the [https://bugs.kde.org/buglist.cgi?quicksearch=kgpg developers].<br />
<br />
=== Conflicts between gnome-keyring and gpg-agent ===<br />
<br />
{{Accuracy|See [[#GPG_AGENT_INFO]]}}<br />
<br />
While the Gnome keyring implements a GPG agent component, as of GnuPG version 2.1, GnuPG ignores the {{ic|GPG_AGENT_INFO}} environment variable, so that Gnome keyring can no longer be used as a GPG agent.<br />
<br />
However, since version 0.9.6 the package {{Pkg|pinentry}} provides the {{Ic|pinentry-gnome3}} program. You may set the following option in your {{Ic|gpg-agent.conf}} file<br />
pinentry-program /usr/bin/pinentry-gnome3<br />
in order to make use of that pinentry program.<br />
<br />
Since version 0.9.2 all pinentry programs can be configured to optionally save a passphrase with libsecret. For example, when the user is asked for a passphrase via {{Ic|pinentry-gnome3}}, a checkbox is shown whether to save the passphrase using a password manager. Unfortunately, the package {{Pkg|pinentry}} does not have this feature enabled (see {{Bug|46059}} for the reasons). You may use {{AUR|pinentry-libsecret}} as a replacement for it, which has support for libsecret enabled.<br />
<br />
=== mutt and gpg ===<br />
<br />
To be asked for your GnuPG password only once per session as of GnuPG 2.1, see [https://bbs.archlinux.org/viewtopic.php?pid=1490821#p1490821 this forum thread].<br />
<br />
=== "Lost" keys, upgrading to gnupg version 2.1 ===<br />
<br />
When {{ic|gpg --list-keys}} fails to show keys that used to be there, and applications complain about missing or invalid keys, some keys may not have been migrated to the new format.<br />
<br />
Please read [http://jo-ke.name/wp/?p=111 GnuPG invalid packet workaround]. Basically, it says that there is a bug with keys in the old {{ic|pubring.gpg}} and {{ic|secring.gpg}} files, which have now been superseded by the new {{ic|pubring.kbx}} file and the {{ic|private-keys-v1.d/}} subdirectory and files. Your missing keys can be recovered with the following commnads:<br />
<br />
$ cd<br />
$ cp -r .gnupg gnupgOLD<br />
$ gpg --export-ownertrust > otrust.txt<br />
$ gpg --import .gnupg/pubring.gpg<br />
$ gpg --import-ownertrust otrust.txt<br />
$ gpg --list-keys<br />
<br />
=== gpg hanged for all keyservers (when trying to receive keys) ===<br />
<br />
If gpg hanged with a certain keyserver when trying to receive keys, you might need to kill dirmngr in order to get access to other keyservers which are actually working, otherwise it might keeping hanging for all of them.<br />
<br />
=== Smartcard not detected ===<br />
<br />
Your user might not have the permission to access the smartcard which results in a {{ic|card error}} to be thrown, even though the card is correctly set up and inserted.<br />
<br />
One possible solution is to add a new group {{ic|scard}} including the users who need access to the smartcard.<br />
<br />
Then use an [[Udev#Writing_udev_rules|udev]] rule, similar to the following:<br />
{{hc|/etc/udev/rules.d/71-gnupg-ccid.rules|<nowiki><br />
ACTION=="add", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="1050", ENV{ID_MODEL_ID}=="0116|0111", MODE="660", GROUP="scard"<br />
</nowiki>}}<br />
One needs to adapt VENDOR and MODEL according to the {{ic|lsusb}} output, the above example is for a YubikeyNEO.<br />
<br />
== See also ==<br />
<br />
* [https://gnupg.org/ GNU Privacy Guard Homepage]<br />
* [https://fedoraproject.org/wiki/Creating_GPG_Keys Creating GPG Keys (Fedora)]<br />
* [https://wiki.debian.org/Subkeys OpenPGP subkeys in Debian]<br />
* [http://blog.sanctum.geek.nz/series/linux-crypto/ A more comprehensive gpg Tutorial]<br />
* [https://help.riseup.net/en/security/message-security/openpgp/gpg-best-practices gpg.conf recommendations and best practices]<br />
* [https://github.com/ioerror/torbirdy/blob/master/gpg.conf Torbirdy gpg.conf]<br />
* [https://www.reddit.com/r/GPGpractice/ /r/GPGpractice - a subreddit to practice using GnuPG.]</div>Ritkahttps://wiki.archlinux.org/index.php?title=GnuPG&diff=434682GnuPG2016-05-11T18:29:21Z<p>Ritka: /* Encrypt and decrypt */ Edited Tip-box: removed tip about '-r' since it is include in the main example, added '--armor' since it was removed from main example but is still useful</p>
<hr />
<div>[[Category:Encryption]]<br />
[[es:GnuPG]]<br />
[[ja:GnuPG]]<br />
[[ru:GnuPG]]<br />
[[zh-cn:GnuPG]]<br />
{{Related articles start}}<br />
{{Related|pacman/Package signing}}<br />
{{Related|Disk encryption}}<br />
{{Related|List of applications/Security#Encryption, signing, steganography}}<br />
{{Related articles end}}<br />
<br />
According to the [http://www.gnupg.org official website]:<br />
<br />
:GnuPG is a complete and free implementation of the OpenPGP standard as defined by RFC4880 (also known as [[Wikipedia:PGP|PGP]]). GnuPG allows to encrypt and sign your data and communication, features a versatile key management system as well as access modules for all kinds of public key directories. GnuPG, also known as GPG, is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries are available. Version 2 of GnuPG also provides support for S/MIME and Secure Shell (ssh).<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|gnupg}} package.<br />
<br />
This will also install {{Pkg|pinentry}}, a collection of simple PIN or passphrase entry dialogs which GnuPG uses for passphrase entry. Which ''pinentry'' dialog is used is determined by the symbolic link {{ic|/usr/bin/pinentry}}, which by default points to {{ic|/usr/bin/pinentry-gtk-2}}.<br />
<br />
If you want to use a graphical frontend or program that integrates with GnuPG, see [[List of applications/Security#Encryption, signing, steganography]].<br />
<br />
== Configuration ==<br />
<br />
=== Directory location ===<br />
{{ic|$GNUPGHOME}} is used by GnuPG to point to the directory where its configuration files are stored. By default {{ic|$GNUPGHOME}} is not set and your {{ic|$HOME}} is used instead; thus, you will find a {{ic|~/.gnupg}} directory right after installation. <br />
<br />
To change the default location, either run gpg this way {{ic|$ gpg --homedir ''path/to/file''}} or set {{ic|GNUPGHOME}} in one of your regular [[startup files]].<br />
<br />
=== Configuration files ===<br />
<br />
The default configuration files are {{ic|~/.gnupg/gpg.conf}} and {{ic|~/.gnupg/dirmngr.conf}}. <br />
<br />
By default, the gnupg directory has its [[permissions]] set to {{ic|700}} and the files it contains have their permissions set to {{ic|600}}. Only the owner of the directory has permission to read, write, and access the files. This is for security purposes and should not be changed. In case this directory or any file inside it does not follow this security measure, you will get warnings about unsafe file and home directory permissions.<br />
<br />
Append to these files any long options you want. Do not write the two dashes, but simply the name of the option and required arguments. You will find skeleton files in {{ic|/usr/share/gnupg}}. These files are copied to {{ic|~/.gnupg}} the first time gpg is run if they do not exist there. Other examples are found in [[#See also]].<br />
<br />
Additionally, [[pacman]] uses a different set of configuration files for package signature verification. See [[Pacman/Package signing]] for details.<br />
<br />
=== Default options for new users ===<br />
<br />
If you want to setup some default options for new users, put configuration files in {{ic|/etc/skel/.gnupg/}}. When the new user is added in system, files from here will be copied to its GnuPG home directory. There is also a simple script called ''addgnupghome'' which you can use to create new GnuPG home directories for existing users:<br />
<br />
# addgnupghome user1 user2<br />
<br />
This will add the respective {{ic|/home/user1/.gnupg}} and {{ic|/home/user2/.gnupg}} and copy the files from the skeleton directory to it. Users with existing GnuPG home directory are simply skipped.<br />
<br />
== Usage ==<br />
<br />
{{Note|Whenever a ''{{ic|<user-id>}}'' is required in a command, it can be specified with your key ID, fingerprint, a part of your name or email address, etc. GnuPG is flexible on this.<br />
}}<br />
<br />
=== Create key pair ===<br />
<br />
Generate a key pair by typing in a terminal:<br />
<br />
$ gpg --full-gen-key<br />
<br />
{{Tip|Use the {{ic|--expert}} option for getting alternative ciphers like [[wikipedia:Elliptic_curve_cryptography|ECC]].}}<br />
<br />
The command will prompt for answers to several questions. For general use most people will want: <br />
<br />
* the RSA (sign only) and a RSA (encrypt only) key.<br />
* a keysize of the default value (2048). A larger keysize of 4096 "gives us almost nothing, while costing us quite a lot"[https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096].<br />
* an expiration date. A period of a year is good enough for the average user. This way even if access is lost to the keyring, it will allow others to know that it is no longer valid. Later, if necessary, the expiration date can be extended without having to re-issue a new key.<br />
* your name and email address. You can add multiple identities to the same key later (''e.g.'', if you have multiple email addresses you want to associate with this key).<br />
* ''no'' optional comment. Since the semantics of the comment field are [https://lists.gnupg.org/pipermail/gnupg-devel/2015-July/030150.html not well-defined], it has limited value for identification.<br />
* [[Security#Choosing_secure_passwords|a secure passphrase]].<br />
<br />
{{Note|The name and email address you enter here will be seen by anybody who imports your key.}}<br />
<br />
=== List keys ===<br />
<br />
To list keys in your public key ring:<br />
<br />
$ gpg --list-keys<br />
<br />
To list keys in your secret key ring:<br />
<br />
$ gpg --list-secret-keys<br />
<br />
=== Export your public key ===<br />
<br />
In order for others to send encrypted messages to you, they need your public key.<br />
<br />
To generate an ASCII version of your public key (''e.g.'' to distribute it by e-mail):<br />
<br />
$ gpg --armor --output ''public.key'' --export ''<user-id>''<br />
<br />
Alternatively, or in addition, you can [[#Use a keyserver]] to share your key. <br />
<br />
{{Tip|Add {{ic|--no-emit-version}} to avoid printing the version number, or add the corresponding setting to your configuration file.}}<br />
<br />
=== Import a key ===<br />
<br />
In order to encrypt messages to others, as well as verify their signatures, you need their public key. To import a public key with file name {{ic|''public.key''}} to your public key ring:<br />
<br />
$ gpg --import ''public.key''<br />
<br />
Alternatively, [[#Use a keyserver]] to find a public key.<br />
<br />
=== Use a keyserver ===<br />
<br />
You can register your key with a public PGP key server, so that others can retrieve your key without having to contact you directly:<br />
<br />
$ gpg --send-keys ''<key-id>''<br />
<br />
To find out details of a key on the keyserver, without importing it, do:<br />
<br />
$ gpg --search-keys ''<key-id>''<br />
<br />
To import a key from a key server:<br />
<br />
$ gpg --recv-keys ''<key-id>''<br />
<br />
{{Warning|Anyone can send keys to a keyserver, so you should not trust that the key you download actually belongs to the individual listed. You should verify the authenticity of the retrieved public key by comparing its fingerprint with one that the owner published on an independent source, such as their own blog or website, or contacting them by email, over the phone or in person. Using multiple authentication sources will increase the level of trust you can give to the downloaded key. See [[Wikipedia:Public key fingerprint]] for more information.}}<br />
<br />
{{Tip|<br />
* Adding {{ic|keyserver-options auto-key-retrieve}} to {{ic|gpg.conf}} will automatically fetch keys from the key server as needed.<br />
* An alternative key server is {{ic|pool.sks-keyservers.net}} and can be specified with {{ic|keyserver}} in {{ic|dirmngr.conf}}.; see also [[wikipedia:Key server (cryptographic)#Keyserver examples]].<br />
* You can connect to the keyserver over [[Tor]] using {{ic|--use-tor}}. {{ic|hkp://jijrk5u4osbsr34t5.onion}} is the onion address for the sks-keyservers pool. [https://gnupg.org/blog/20151224-gnupg-in-november-and-december.html See this GnuPG blog post] for more information.<br />
* You can connect to a keyserver using a proxy by setting the {{ic|http_proxy}} environment variable and setting {{ic|honor-http-proxy}} in {{ic|dirmngr.conf}}. Alternatively, set {{ic|http-proxy ''host[:port]''}} in {{ic|dirmngr.conf}}, overriding the {{ic|http_proxy}} environment variable.}}<br />
<br />
=== Encrypt and decrypt ===<br />
<br />
gpg's main usage is public-key cryptography (see [[Wikipedia:Public-key cryptography]]). That means, you usually use a users public key to encrypt files and you use your private key to decrypt them.<br />
<br />
To encrypt a file with the name ''doc'', use:<br />
<br />
$ gpg -e -r ''<user-id>'' ''doc''<br />
<br />
where ''<user-id>'' should refer to the user who shall be able to decrypt the file. Note that you need to import the users public key before.<br />
<br />
{{Tip|<br />
* Add {{ic|--armor}} to encrypt a file using ASCII armor (suitable for copying and pasting a message in text format)<br />
* Use {{ic|-R ''<user-id>''}} or {{ic|--hidden-recipient ''<user-id>''}} instead of {{ic|-r}} to not put the recipient key IDs in the encrypted message. This helps to hide the receivers of the message and is a limited countermeasure against traffic analysis.<br />
* Add {{ic|--no-emit-version}} to avoid printing the version number, or add the corresponding setting to your configuration file.}}<br />
<br />
{{Note|You can use gnupg to encrypt your sensitive documents, but only individual files at a time. If you want to encrypt directories or a whole file-system you should consider using [[TrueCrypt]] or [[EncFS]], though you can always tarball various files and then encrypt them.}}<br />
<br />
To decrypt a file encrypted with your public key, use:<br />
<br />
$ gpg --decrypt ''doc.asc''<br />
<br />
You will be prompted to enter your passphrase.<br />
<br />
== Key maintenance ==<br />
<br />
=== Backup your private key ===<br />
<br />
To backup your private key do the following:<br />
<br />
$ gpg --export-secret-keys --armor ''<user-id>'' > ''privkey.asc''<br />
<br />
Note that ''gpg'' release 2.1 changed default behaviour so that the above command enforces a passphrase protection, even if you deliberately chose not to use one on key creation. This is because otherwise anyone who gains access to the above exported file would be able to encrypt and sign documents as if they were you ''without'' needing to know your passphrase. <br />
<br />
{{Warning|The passphrase is usually the weakest link in protecting your secret key. Place the private key in a safe place on a different system/device, such as a locked container or encrypted drive. It is the only safety you have to regain control to your keyring in case of, for example, a drive failure, theft or worse.}}<br />
<br />
=== Edit your key ===<br />
<br />
Running the {{ic|gpg --edit-key ''<user-id>''}} command will present a menu which enables you to do most of your key management related tasks.<br />
<br />
Some useful commands in the edit key sub menu:<br />
> passwd # change the passphrase<br />
> clean # compact any user ID that is no longer usable (e.g revoked or expired)<br />
> revkey # revoke a key<br />
> addkey # add a subkey to this key<br />
> expire # change the key expiration time<br />
<br />
Type {{ic|help}} in the edit key sub menu for more commands.<br />
<br />
{{Tip|If you have multiple email accounts you can add each one of them as an identity, using {{ic|adduid}} command. You can then set your favourite one as {{ic|primary}}.}}<br />
<br />
=== Exporting subkey ===<br />
<br />
If you plan to use the same key across multiple devices, you may want to strip out your master key and only keep the bare minimum encryption subkey on less secure systems.<br />
<br />
First, find out which subkey you want to export.<br />
<br />
$ gpg -K<br />
<br />
Select only that subkey to export.<br />
<br />
$ gpg -a --export-secret-subkeys [subkey id]! > /tmp/subkey.gpg<br />
<br />
{{Warning|If you forget to add the !, all of your subkeys will be exported.}}<br />
<br />
At this point you could stop, but it is most likely a good idea to change the passphrase as well. Import the key into a temporary folder. <br />
<br />
$ gpg --homedir /tmp/gpg --import /tmp/subkey.gpg<br />
$ gpg --homedir /tmp/gpg --edit-key ''<user-id>''<br />
> passwd<br />
> save<br />
$ gpg --homedir /tmp/gpg -a --export-secret-subkeys [subkey id]! > /tmp/subkey.altpass.gpg<br />
<br />
{{Note|You will get a warning that the master key was not available and the password was not changed, but that can safely be ignored as the subkey password was.}}<br />
<br />
At this point, you can now use {{ic|/tmp/subkey.altpass.gpg}} on your other devices.<br />
<br />
=== Rotating subkeys ===<br />
<br />
{{Warning|'''Never''' delete your expired or revoked subkeys unless you have a good reason. Doing so will cause you to lose the ability to decrypt files encrypted with the old subkey. Please '''only''' delete expired or revoked keys from other users to clean your keyring.}}<br />
<br />
If you have set your subkeys to expire after a set time, you can create new ones. Do this a few weeks in advance to allow others to update their keyring.<br />
<br />
{{Note|You do not need to create a new key simply because it is expired. You can extend the expiration date.}}<br />
<br />
Create new subkey (repeat for both signing and encrypting key)<br />
<br />
$ gpg --edit-key ''<user-id>''<br />
> addkey<br />
<br />
And answer the following questions it asks (see previous section for suggested settings).<br />
<br />
Save changes<br />
<br />
> save<br />
<br />
Update it to a keyserver.<br />
<br />
$ gpg --keyserver pgp.mit.edu --send-keys ''<user-id>''<br />
<br />
{{Note|Revoking expired subkeys is unnecessary and arguably bad form. If you are constantly revoking keys, it may cause others to lack confidence in you.}}<br />
<br />
== Signatures ==<br />
<br />
Signatures certify and timestamp documents. If the document is modified, verification of the signature will fail. Unlike encryption which uses public keys to encrypt a document, signatures are created with the user's private key. The recipient of a signed document then verifies the signature using the sender's public key.<br />
<br />
=== Sign a file ===<br />
<br />
To sign a file use the {{ic|--sign}} or {{ic|-s}} flag:<br />
<br />
$ gpg --output ''doc.sig'' --sign ''doc''<br />
<br />
The above also encrypts the file and stores it in binary format.<br />
<br />
=== Clearsign a file or message ===<br />
<br />
To sign a file without compressing it into binary format use:<br />
<br />
$ gpg --clearsign ''doc''<br />
<br />
This wraps the document into an ASCII-armored signature, but does not modify the document.<br />
<br />
=== Make a detached signature ===<br />
<br />
To create a separate signature file to be distributed separately from the document or file itself, use the {{ic|--detach-sig}} flag:<br />
<br />
$ gpg --output ''doc.sig'' --detach-sig ''doc''<br />
<br />
This method is often used in distributing software projects to allow users to verify that the program has not been modified by a third part.<br />
<br />
=== Verify a signature ===<br />
<br />
To verify a signature use the {{ic|--verify}} flag:<br />
<br />
$ gpg --verify ''doc.sig''<br />
<br />
where {{ic|''doc.sig''}} is the signature you wish to verify.<br />
<br />
To verify and decrypt a file at the same time, use the {{ic|--decrypt}} flag as you normally would in decrypting a file.<br />
<br />
If you are verifying a detached signature, both the file and the signature must be present when verifying. For example, to verify Arch Linux's latest iso you would do:<br />
<br />
$ gpg --verify ''archlinux-<version>-dual.iso.sig''<br />
<br />
where {{ic|''archlinux-<version>-dual.iso''}} must be located in the same directory.<br />
<br />
== gpg-agent ==<br />
<br />
''gpg-agent'' is mostly used as daemon to request and cache the password for the keychain. This is useful if GnuPG is used from an external program like a mail client.<br />
<br />
Starting with GnuPG 2.1.0 the use of ''gpg-agent'' is required. ''gpg-agent'' is started on-demand by the GnuPG tools, so there is usually no reason to start it manually.<br />
<br />
=== Configuration ===<br />
<br />
gpg-agent can be configured via {{ic|~/.gnupg/gpg-agent.conf}} file. The configuration options are listed in {{ic|man gpg-agent}}. For example you can change cache ttl for unused keys:<br />
<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
default-cache-ttl 3600<br />
}}<br />
<br />
{{Tip|To cache your passphrase for the whole session, please run the following command:<br />
$ /usr/lib/gnupg/gpg-preset-passphrase --preset XXXXXX<br />
<br />
where XXXX is the keygrip. You can get its value when running {{ic|gpg --with-keygrip -K}}. Passphrase will be stored until {{ic|gpg-agent}} is restarted. If you set up {{ic|default-cache-ttl}} value, it will take precedence.<br />
}}<br />
<br />
=== Reload the agent ===<br />
<br />
After changing the configuration, reload the agent using ''gpg-connect-agent'':<br />
<br />
$ gpg-connect-agent reloadagent /bye<br />
<br />
The command should print {{ic|OK}}.<br />
<br />
=== pinentry ===<br />
<br />
Finally, the agent needs to know how to ask the user for the password. This can be set in the gpg-agent configuration file.<br />
<br />
The default uses a gtk dialog. There are other options - see {{ic|info pinentry}}. To change the dialog implementation set {{ic|pinentry-program}} configuration option:<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
<br />
# PIN entry program<br />
# pinentry-program /usr/bin/pinentry-curses<br />
# pinentry-program /usr/bin/pinentry-qt<br />
# pinentry-program /usr/bin/pinentry-kwallet<br />
<br />
pinentry-program /usr/bin/pinentry-gtk-2<br />
}}<br />
<br />
{{Tip|For using {{ic|/usr/bin/pinentry-kwallet}} you have to install the {{Pkg|kwalletcli}} package.}}<br />
<br />
After making this change, reload the gpg-agent.<br />
<br />
=== Start gpg-agent with systemd user ===<br />
<br />
It is possible to use the [[Systemd/User]] facilities to start the agent.<br />
<br />
Create a systemd unit file:<br />
<br />
{{hc|~/.config/systemd/user/gpg-agent.service|2=<br />
[Unit]<br />
Description=GnuPG private key agent<br />
IgnoreOnIsolate=true<br />
<br />
[Service]<br />
Type=forking<br />
ExecStart=/usr/bin/gpg-agent --daemon<br />
Restart=on-abort<br />
<br />
[Install]<br />
WantedBy=default.target<br />
}}<br />
<br />
{{Note|If you use non-default value for the [[#GNUPGHOME]] environment variable, you need to pass it to the service. See [[systemd/User#Environment variables]] for details.}}<br />
<br />
=== Unattended passphrase ===<br />
<br />
Starting with GnuPG 2.1.0 the use of gpg-agent and pinentry is required, which may break backwards compatibility for passphrases piped in from STDIN using the {{ic|--passphrase-fd 0}} commandline option. In order to have the same type of functionality as the older releases two things must be done:<br />
<br />
First, edit the gpg-agent configuration to allow ''loopback'' pinentry mode:<br />
<br />
{{hc|1=~/.gnupg/gpg-agent.conf|2=<br />
allow-loopback-pinentry<br />
}}<br />
<br />
Restart the gpg-agent process if it is running to let the change take effect.<br />
<br />
Second, either the application needs to be updated to include a commandline parameter to use loopback mode like so:<br />
<br />
$ gpg --pinentry-mode loopback ...<br />
<br />
...or if this is not possible, add the option to the configuration:<br />
<br />
{{hc|1=~/.gnupg/gpg.conf|2=<br />
pinentry-mode loopback<br />
}}<br />
<br />
{{Note|The upstream author indicates setting {{ic|pinentry-mode loopback}} in {{ic|gpg.conf}} may break other usage, using the commandline option should be preferred if at all possible. [https://bugs.g10code.com/gnupg/issue1772]}}<br />
<br />
=== SSH agent ===<br />
<br />
''gpg-agent'' has OpenSSH agent emulation. If you already use the GnuPG suite, you might consider using its agent to also cache your SSH keys. Additionally, some users may prefer the PIN entry dialog GnuPG agent provides as part of its passphrase management.<br />
<br />
To start using GnuPG agent for your SSH keys, enable SSH support in the {{ic|~/.gnupg/gpg-agent.conf}} file:<br />
<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
enable-ssh-support<br />
}}<br />
<br />
Next, make sure that ''gpg-agent'' is always started. Use either the [[#Start gpg-agent with systemd user|systemd user service]] or add the following to your {{ic|.bashrc}} file:<br />
<br />
{{hc|~/.bashrc|<nowiki><br />
# Start the gpg-agent if not already running<br />
if ! pgrep -x -u "${USER}" gpg-agent >/dev/null 2>&1; then<br />
gpg-connect-agent /bye >/dev/null 2>&1<br />
fi<br />
</nowiki>}}<br />
<br />
Then set {{ic|SSH_AUTH_SOCK}} so that SSH will use ''gpg-agent'' instead of ''ssh-agent'':<br />
<br />
{{hc|~/.bashrc|<nowiki><br />
# Set SSH to use gpg-agent<br />
unset SSH_AGENT_PID<br />
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then<br />
export SSH_AUTH_SOCK="${HOME}/.gnupg/S.gpg-agent.ssh"<br />
fi<br />
</nowiki>}}<br />
<br />
Also set the GPG TTY and refresh the TTY in case user has switched into an X session. Example:<br />
<br />
{{Expansion|Not clear why this is necessary (even tha man page does not explain it).}}<br />
<br />
{{hc|~/.bashrc|<nowiki><br />
# Set GPG TTY<br />
export GPG_TTY=$(tty)<br />
<br />
# Refresh gpg-agent tty in case user switches into an X session<br />
gpg-connect-agent updatestartuptty /bye >/dev/null<br />
</nowiki>}}<br />
<br />
Once ''gpg-agent'' is running you can use ''ssh-add'' to approve keys, following the same steps as for [[SSH keys#ssh-agent|ssh-agent]]. The list of approved keys is stored in the {{ic|~/.gnupg/sshcontrol}} file. Once your key is approved, you will get a ''pinentry'' dialog every time your passphrase is needed. You can control passphrase caching in the {{ic|~/.gnupg/gpg-agent.conf}} file. The following example would have ''gpg-agent'' cache your keys for 3 hours:<br />
<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
default-cache-ttl-ssh 10800<br />
}}<br />
<br />
== Smartcards ==<br />
<br />
GnuPG uses ''scdaemon'' as an interface to your smartcard reader, please refer to the [[man page]] for details.<br />
<br />
=== GnuPG only setups ===<br />
<br />
{{Note| To allow scdaemon direct access to USB smarcard readers the optional dependency {{Pkg|libusb-compat}} have to be installed}}<br />
<br />
If you do not plan to use other cards but those based on GnuPG, you should check the {{Ic|reader-port}} parameter in {{ic|~/.gnupg/scdaemon.conf}}. The value '0' refers to the first available serial port reader and a value of '32768' (default) refers to the first USB reader.<br />
<br />
=== GnuPG with PSCD-Lite ===<br />
<br />
{{Note|{{Pkg|pcsclite}} and {{Pkg|ccid}} have to be installed, and the contained [[systemd#Using units|systemd]] service {{ic|pcscd.service}} has to be running, or the socket {{ic|pscd.socket}} has to be listening.}}<br />
<br />
PSCD-Lite is a daemon which handles access to smartcard (SCard API). If GnuPG's scdaemon fails to connect the smartcard directly (e.g. by using its integrated CCID support), it will fallback and try to find a smartcard using the PSCD-Lite driver.<br />
<br />
==== Always use PSCD-Light ====<br />
<br />
If you are using any smartcard with an opensc driver (e.g.: ID cards from some countries) you should pay some attention to GnuPG configuration. Out of the box you might receive a message like this when using {{Ic|gpg --card-status}}<br />
<br />
gpg: selecting openpgp failed: ec=6.108<br />
<br />
By default, scdaemon will try to connect directly to the device. This connection will fail if the reader is being used by another process. For example: the pcscd daemon used by OpenSC. To cope with this situation we should use the same underlying driver as opensc so they can work well together. In order to point scdaemon to use pcscd you should remove {{Ic|reader-port}} from {{ic|~/.gnupg/scdaemon.conf}}, specify the location to {{ic|libpcsclite.so}} library and disable ccid so we make sure that we use pcscd:<br />
<br />
{{hc|~/.gnupg/scdaemon.conf|<nowiki><br />
pcsc-driver /usr/lib/libpcsclite.so<br />
card-timeout 5<br />
disable-ccid<br />
</nowiki>}}<br />
<br />
Please check {{Ic|man scdaemon}} if you do not use OpenSC.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Different algorithm ===<br />
<br />
You may want to use stronger algorithms:<br />
<br />
{{hc|~/.gnupg/gpg.conf|<br />
...<br />
<br />
personal-digest-preferences SHA512<br />
cert-digest-algo SHA512<br />
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed<br />
personal-cipher-preferences TWOFISH CAMELLIA256 AES 3DES<br />
}}<br />
<br />
In the latest version of GnuPG, the default algorithms used are SHA256 and AES, both of which are secure enough for most people. However, if you are using a version of GnuPG older than 2.1, or if you want an even higher level of security, then you should follow the above step.<br />
<br />
=== Encrypt a password ===<br />
<br />
It can be useful to encrypt some password, so it will not be written in clear on a configuration file. A good example is your email password.<br />
<br />
First create a file with your password. You '''need''' to leave '''one''' empty line after the password, otherwise gpg will return an error message when evaluating the file.<br />
<br />
Then run:<br />
<br />
$ gpg -e -a -r ''<user-id>'' ''your_password_file''<br />
<br />
{{ic|-e}} is for encrypt, {{ic|-a}} for armor (ASCII output), {{ic|-r}} for recipient user ID.<br />
<br />
You will be left with a new {{ic|''your_password_file''.asc}} file.<br />
<br />
=== Revoking a key ===<br />
<br />
{{Warning|<br />
*Anybody having access to your revocation certificate can revoke your key, rendering it useless.<br />
*Key revocation should only be performed if your key is compromised or lost, or you forget your passphrase.}}<br />
<br />
Revocation certificates are automatically generated for newly generated keys, although one can be generated manually by the user later. These are located at {{ic|~/.gnupg/openpgp-revocs.d/}}. The filename of the certificate is the fingerprint of the key it will revoke.<br />
<br />
To revoke your key, simply import the revocation certificate:<br />
<br />
$ gpg --import ''<fingerprint>''.rev<br />
<br />
Now update the keyserver:<br />
<br />
$ gpg --keyserver subkeys.pgp.net --send ''<userid>''<br />
<br />
=== Change trust model ===<br />
<br />
By default GnuPG uses the [[Wikipedia::Web of Trust|Web of Trust]] as the trust model. You can change this to [[Wikipedia::Trust on First|Trust on First]] Use by adding {{ic|1=--trust-model=tofu}} when adding a key or adding this option to your GnuPG configuration file. More details are in [https://lists.gnupg.org/pipermail/gnupg-devel/2015-October/030341.html this email to the GnuPG list].<br />
<br />
=== Hide all recipient id's ===<br />
<br />
By default the recipient's key ID is in the encrypted message. This can be removed at encryption time for a recipient by using {{ic|hidden-recipient ''<user-id>''}}. To remove it for all recipients add {{ic|throw-keyids}} to your configuration file. This helps to hide the receivers of the message and is a limited countermeasure against traffic analysis. (Using a little social engineering anyone who is able to decrypt the message can check whether one of the other recipients is the one he suspects.) On the receiving side, it may slow down the decryption process because all available secret keys must be tried (''e.g.'' with {{ic|--try-secret-key ''<user-id>''}}).<br />
<br />
=== Using caff for keysigning parties ===<br />
<br />
To allow users to validate keys on the keyservers and in their keyrings (i.e. make sure they are from whom they claim to be), PGP/GPG uses he [[Wikipedia::Web of Trust|Web of Trust]]. Keysigning parties allow users to get together in physical location to validate keys. The [[Wikipedia:Zimmermann–Sassaman key-signing protocol|Zimmermann-Sassaman]] key-signing protocol is a way of making these very effective. [http://www.cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html Here] you will find a how-to article.<br />
<br />
For an easier process of signing keys and sending signatures to the owners after a keysigning party, you can use the tool ''caff''. It can be installed from the AUR with the package {{AUR|caff-svn}} or bundled together with other useful tools in the package {{AUR|signing-party-svn}}{{Broken package link|{{aur-mirror|signing-party-svn}}}}.<br />
Either way, there will be a lot of dependencies installing from the AUR. Alternatively you can install them from CPAN with<br />
cpanm Any::Moose<br />
cpanm GnuPG::Interface<br />
<br />
To send the signatures to their owners you need a working [[Wikipedia:Message transfer agent|MTA]]. If you do not have already one, install [[msmtp]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Not enough random bytes available ===<br />
When generating a key, gpg can run into this error:<br />
Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy!<br />
To check the available entropy, check the kernel parameters:<br />
cat /proc/sys/kernel/random/entropy_avail<br />
A healthy Linux system with a lot of entropy available will have return close to the full 4,096 bits of entropy. If the value returned is less than 200, the system is running low on entropy. <br />
<br />
To solve it, remember you do not often need to create keys and best just do what the message suggests (e.g. create disk activity, move the mouse, edit the wiki - all will create entropy). If that does not help, check which service is using up the entropy and consider stopping it for the time. If that is no alternative, see [[Random number generation#Faster alternatives]].<br />
<br />
=== su ===<br />
<br />
When using {{Ic|pinentry}}, you must have the proper permissions of the terminal device (e.g. {{Ic|/dev/tty1}}) in use. However, with ''su'' (or ''sudo''), the ownership stays with the original user, not the new one. This means that pinentry will fail, even as root. The fix is to change the permissions of the device at some point before the use of pinentry (i.e. using gpg with an agent). If doing gpg as root, simply change the ownership to root right before using gpg:<br />
<br />
chown root /dev/ttyN # where N is the current tty<br />
<br />
and then change it back after using gpg the first time. The equivalent is likely to be true with {{Ic|/dev/pts/}}.<br />
<br />
{{Note|The owner of tty ''must'' match with the user for which pinentry is running. Being part of the group {{Ic|tty}} '''is not''' enough.}}<br />
<br />
=== Agent complains end of file ===<br />
<br />
The default pinentry program is pinentry-gtk-2, which needs a DBus session bus to run properly. See [[General troubleshooting#Session permissions]] for details.<br />
<br />
Alternatively, you can use {{ic|pinentry-qt}}. See [[#pinentry]].<br />
<br />
=== KGpg configuration permissions ===<br />
<br />
There have been issues with {{Pkg|kdeutils-kgpg}} being able to access the {{ic|~/.gnupg/}} options. One issue might be a result of a deprecated ''options'' file, see the [https://bugs.kde.org/show_bug.cgi?id=290221 bug] report.<br />
<br />
Another user reported that ''KGpg'' failed to start until the {{ic|~/.gnupg}} folder is set to {{ic|drwxr-xr-x}} permissions. If you require this work-around, ensure that the directory contents retain {{ic|-rw-------}} permissions! Further, report it as a bug to the [https://bugs.kde.org/buglist.cgi?quicksearch=kgpg developers].<br />
<br />
=== Conflicts between gnome-keyring and gpg-agent ===<br />
<br />
{{Accuracy|See [[#GPG_AGENT_INFO]]}}<br />
<br />
While the Gnome keyring implements a GPG agent component, as of GnuPG version 2.1, GnuPG ignores the {{ic|GPG_AGENT_INFO}} environment variable, so that Gnome keyring can no longer be used as a GPG agent.<br />
<br />
However, since version 0.9.6 the package {{Pkg|pinentry}} provides the {{Ic|pinentry-gnome3}} program. You may set the following option in your {{Ic|gpg-agent.conf}} file<br />
pinentry-program /usr/bin/pinentry-gnome3<br />
in order to make use of that pinentry program.<br />
<br />
Since version 0.9.2 all pinentry programs can be configured to optionally save a passphrase with libsecret. For example, when the user is asked for a passphrase via {{Ic|pinentry-gnome3}}, a checkbox is shown whether to save the passphrase using a password manager. Unfortunately, the package {{Pkg|pinentry}} does not have this feature enabled (see {{Bug|46059}} for the reasons). You may use {{AUR|pinentry-libsecret}} as a replacement for it, which has support for libsecret enabled.<br />
<br />
=== mutt and gpg ===<br />
<br />
To be asked for your GnuPG password only once per session as of GnuPG 2.1, see [https://bbs.archlinux.org/viewtopic.php?pid=1490821#p1490821 this forum thread].<br />
<br />
=== "Lost" keys, upgrading to gnupg version 2.1 ===<br />
<br />
When {{ic|gpg --list-keys}} fails to show keys that used to be there, and applications complain about missing or invalid keys, some keys may not have been migrated to the new format.<br />
<br />
Please read [http://jo-ke.name/wp/?p=111 GnuPG invalid packet workaround]. Basically, it says that there is a bug with keys in the old {{ic|pubring.gpg}} and {{ic|secring.gpg}} files, which have now been superseded by the new {{ic|pubring.kbx}} file and the {{ic|private-keys-v1.d/}} subdirectory and files. Your missing keys can be recovered with the following commnads:<br />
<br />
$ cd<br />
$ cp -r .gnupg gnupgOLD<br />
$ gpg --export-ownertrust > otrust.txt<br />
$ gpg --import .gnupg/pubring.gpg<br />
$ gpg --import-ownertrust otrust.txt<br />
$ gpg --list-keys<br />
<br />
=== gpg hanged for all keyservers (when trying to receive keys) ===<br />
<br />
If gpg hanged with a certain keyserver when trying to receive keys, you might need to kill dirmngr in order to get access to other keyservers which are actually working, otherwise it might keeping hanging for all of them.<br />
<br />
=== Smartcard not detected ===<br />
<br />
Your user might not have the permission to access the smartcard which results in a {{ic|card error}} to be thrown, even though the card is correctly set up and inserted.<br />
<br />
One possible solution is to add a new group {{ic|scard}} including the users who need access to the smartcard.<br />
<br />
Then use an [[Udev#Writing_udev_rules|udev]] rule, similar to the following:<br />
{{hc|/etc/udev/rules.d/71-gnupg-ccid.rules|<nowiki><br />
ACTION=="add", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="1050", ENV{ID_MODEL_ID}=="0116|0111", MODE="660", GROUP="scard"<br />
</nowiki>}}<br />
One needs to adapt VENDOR and MODEL according to the {{ic|lsusb}} output, the above example is for a YubikeyNEO.<br />
<br />
== See also ==<br />
<br />
* [https://gnupg.org/ GNU Privacy Guard Homepage]<br />
* [https://fedoraproject.org/wiki/Creating_GPG_Keys Creating GPG Keys (Fedora)]<br />
* [https://wiki.debian.org/Subkeys OpenPGP subkeys in Debian]<br />
* [http://blog.sanctum.geek.nz/series/linux-crypto/ A more comprehensive gpg Tutorial]<br />
* [https://help.riseup.net/en/security/message-security/openpgp/gpg-best-practices gpg.conf recommendations and best practices]<br />
* [https://github.com/ioerror/torbirdy/blob/master/gpg.conf Torbirdy gpg.conf]<br />
* [https://www.reddit.com/r/GPGpractice/ /r/GPGpractice - a subreddit to practice using GnuPG.]</div>Ritkahttps://wiki.archlinux.org/index.php?title=GnuPG&diff=434681GnuPG2016-05-11T18:23:37Z<p>Ritka: /* Encrypt and decrypt */ Rewrote paragraph about encrytion: Removed the '-u' nonsense, cause you don't need that for encrytion at all, added the -r option to the example command and removed --armor (the former is required by gpg, the latter unnecessay)</p>
<hr />
<div>[[Category:Encryption]]<br />
[[es:GnuPG]]<br />
[[ja:GnuPG]]<br />
[[ru:GnuPG]]<br />
[[zh-cn:GnuPG]]<br />
{{Related articles start}}<br />
{{Related|pacman/Package signing}}<br />
{{Related|Disk encryption}}<br />
{{Related|List of applications/Security#Encryption, signing, steganography}}<br />
{{Related articles end}}<br />
<br />
According to the [http://www.gnupg.org official website]:<br />
<br />
:GnuPG is a complete and free implementation of the OpenPGP standard as defined by RFC4880 (also known as [[Wikipedia:PGP|PGP]]). GnuPG allows to encrypt and sign your data and communication, features a versatile key management system as well as access modules for all kinds of public key directories. GnuPG, also known as GPG, is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries are available. Version 2 of GnuPG also provides support for S/MIME and Secure Shell (ssh).<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|gnupg}} package.<br />
<br />
This will also install {{Pkg|pinentry}}, a collection of simple PIN or passphrase entry dialogs which GnuPG uses for passphrase entry. Which ''pinentry'' dialog is used is determined by the symbolic link {{ic|/usr/bin/pinentry}}, which by default points to {{ic|/usr/bin/pinentry-gtk-2}}.<br />
<br />
If you want to use a graphical frontend or program that integrates with GnuPG, see [[List of applications/Security#Encryption, signing, steganography]].<br />
<br />
== Configuration ==<br />
<br />
=== Directory location ===<br />
{{ic|$GNUPGHOME}} is used by GnuPG to point to the directory where its configuration files are stored. By default {{ic|$GNUPGHOME}} is not set and your {{ic|$HOME}} is used instead; thus, you will find a {{ic|~/.gnupg}} directory right after installation. <br />
<br />
To change the default location, either run gpg this way {{ic|$ gpg --homedir ''path/to/file''}} or set {{ic|GNUPGHOME}} in one of your regular [[startup files]].<br />
<br />
=== Configuration files ===<br />
<br />
The default configuration files are {{ic|~/.gnupg/gpg.conf}} and {{ic|~/.gnupg/dirmngr.conf}}. <br />
<br />
By default, the gnupg directory has its [[permissions]] set to {{ic|700}} and the files it contains have their permissions set to {{ic|600}}. Only the owner of the directory has permission to read, write, and access the files. This is for security purposes and should not be changed. In case this directory or any file inside it does not follow this security measure, you will get warnings about unsafe file and home directory permissions.<br />
<br />
Append to these files any long options you want. Do not write the two dashes, but simply the name of the option and required arguments. You will find skeleton files in {{ic|/usr/share/gnupg}}. These files are copied to {{ic|~/.gnupg}} the first time gpg is run if they do not exist there. Other examples are found in [[#See also]].<br />
<br />
Additionally, [[pacman]] uses a different set of configuration files for package signature verification. See [[Pacman/Package signing]] for details.<br />
<br />
=== Default options for new users ===<br />
<br />
If you want to setup some default options for new users, put configuration files in {{ic|/etc/skel/.gnupg/}}. When the new user is added in system, files from here will be copied to its GnuPG home directory. There is also a simple script called ''addgnupghome'' which you can use to create new GnuPG home directories for existing users:<br />
<br />
# addgnupghome user1 user2<br />
<br />
This will add the respective {{ic|/home/user1/.gnupg}} and {{ic|/home/user2/.gnupg}} and copy the files from the skeleton directory to it. Users with existing GnuPG home directory are simply skipped.<br />
<br />
== Usage ==<br />
<br />
{{Note|Whenever a ''{{ic|<user-id>}}'' is required in a command, it can be specified with your key ID, fingerprint, a part of your name or email address, etc. GnuPG is flexible on this.<br />
}}<br />
<br />
=== Create key pair ===<br />
<br />
Generate a key pair by typing in a terminal:<br />
<br />
$ gpg --full-gen-key<br />
<br />
{{Tip|Use the {{ic|--expert}} option for getting alternative ciphers like [[wikipedia:Elliptic_curve_cryptography|ECC]].}}<br />
<br />
The command will prompt for answers to several questions. For general use most people will want: <br />
<br />
* the RSA (sign only) and a RSA (encrypt only) key.<br />
* a keysize of the default value (2048). A larger keysize of 4096 "gives us almost nothing, while costing us quite a lot"[https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096].<br />
* an expiration date. A period of a year is good enough for the average user. This way even if access is lost to the keyring, it will allow others to know that it is no longer valid. Later, if necessary, the expiration date can be extended without having to re-issue a new key.<br />
* your name and email address. You can add multiple identities to the same key later (''e.g.'', if you have multiple email addresses you want to associate with this key).<br />
* ''no'' optional comment. Since the semantics of the comment field are [https://lists.gnupg.org/pipermail/gnupg-devel/2015-July/030150.html not well-defined], it has limited value for identification.<br />
* [[Security#Choosing_secure_passwords|a secure passphrase]].<br />
<br />
{{Note|The name and email address you enter here will be seen by anybody who imports your key.}}<br />
<br />
=== List keys ===<br />
<br />
To list keys in your public key ring:<br />
<br />
$ gpg --list-keys<br />
<br />
To list keys in your secret key ring:<br />
<br />
$ gpg --list-secret-keys<br />
<br />
=== Export your public key ===<br />
<br />
In order for others to send encrypted messages to you, they need your public key.<br />
<br />
To generate an ASCII version of your public key (''e.g.'' to distribute it by e-mail):<br />
<br />
$ gpg --armor --output ''public.key'' --export ''<user-id>''<br />
<br />
Alternatively, or in addition, you can [[#Use a keyserver]] to share your key. <br />
<br />
{{Tip|Add {{ic|--no-emit-version}} to avoid printing the version number, or add the corresponding setting to your configuration file.}}<br />
<br />
=== Import a key ===<br />
<br />
In order to encrypt messages to others, as well as verify their signatures, you need their public key. To import a public key with file name {{ic|''public.key''}} to your public key ring:<br />
<br />
$ gpg --import ''public.key''<br />
<br />
Alternatively, [[#Use a keyserver]] to find a public key.<br />
<br />
=== Use a keyserver ===<br />
<br />
You can register your key with a public PGP key server, so that others can retrieve your key without having to contact you directly:<br />
<br />
$ gpg --send-keys ''<key-id>''<br />
<br />
To find out details of a key on the keyserver, without importing it, do:<br />
<br />
$ gpg --search-keys ''<key-id>''<br />
<br />
To import a key from a key server:<br />
<br />
$ gpg --recv-keys ''<key-id>''<br />
<br />
{{Warning|Anyone can send keys to a keyserver, so you should not trust that the key you download actually belongs to the individual listed. You should verify the authenticity of the retrieved public key by comparing its fingerprint with one that the owner published on an independent source, such as their own blog or website, or contacting them by email, over the phone or in person. Using multiple authentication sources will increase the level of trust you can give to the downloaded key. See [[Wikipedia:Public key fingerprint]] for more information.}}<br />
<br />
{{Tip|<br />
* Adding {{ic|keyserver-options auto-key-retrieve}} to {{ic|gpg.conf}} will automatically fetch keys from the key server as needed.<br />
* An alternative key server is {{ic|pool.sks-keyservers.net}} and can be specified with {{ic|keyserver}} in {{ic|dirmngr.conf}}.; see also [[wikipedia:Key server (cryptographic)#Keyserver examples]].<br />
* You can connect to the keyserver over [[Tor]] using {{ic|--use-tor}}. {{ic|hkp://jijrk5u4osbsr34t5.onion}} is the onion address for the sks-keyservers pool. [https://gnupg.org/blog/20151224-gnupg-in-november-and-december.html See this GnuPG blog post] for more information.<br />
* You can connect to a keyserver using a proxy by setting the {{ic|http_proxy}} environment variable and setting {{ic|honor-http-proxy}} in {{ic|dirmngr.conf}}. Alternatively, set {{ic|http-proxy ''host[:port]''}} in {{ic|dirmngr.conf}}, overriding the {{ic|http_proxy}} environment variable.}}<br />
<br />
=== Encrypt and decrypt ===<br />
<br />
gpg's main usage is public-key cryptography (see [[Wikipedia:Public-key cryptography]]). That means, you usually use a users public key to encrypt files and you use your private key to decrypt them.<br />
<br />
To encrypt a file with the name ''doc'', use:<br />
<br />
$ gpg -e -r ''<user-id>'' ''doc''<br />
<br />
where ''<user-id>'' should refer to the user who shall be able to decrypt the file. Note that you need to import the users public key before.<br />
<br />
{{Tip|<br />
* If you want to change recipient this can be done by the option {{ic|-r ''<user-id>''}} (or {{ic|--recipient ''<user-id>''}}).<br />
* Add {{ic|-R ''<user-id>''}} or {{ic|--hidden-recipient ''<user-id>''}} instead of {{ic|--recipient}} to not put the recipient key IDs in the encrypted message. This helps to hide the receivers of the message and is a limited countermeasure against traffic analysis.<br />
* Add {{ic|--no-emit-version}} to avoid printing the version number, or add the corresponding setting to your configuration file.}}<br />
<br />
{{Note|You can use gnupg to encrypt your sensitive documents, but only individual files at a time. If you want to encrypt directories or a whole file-system you should consider using [[TrueCrypt]] or [[EncFS]], though you can always tarball various files and then encrypt them.}}<br />
<br />
To decrypt a file encrypted with your public key, use:<br />
<br />
$ gpg --decrypt ''doc.asc''<br />
<br />
You will be prompted to enter your passphrase.<br />
<br />
== Key maintenance ==<br />
<br />
=== Backup your private key ===<br />
<br />
To backup your private key do the following:<br />
<br />
$ gpg --export-secret-keys --armor ''<user-id>'' > ''privkey.asc''<br />
<br />
Note that ''gpg'' release 2.1 changed default behaviour so that the above command enforces a passphrase protection, even if you deliberately chose not to use one on key creation. This is because otherwise anyone who gains access to the above exported file would be able to encrypt and sign documents as if they were you ''without'' needing to know your passphrase. <br />
<br />
{{Warning|The passphrase is usually the weakest link in protecting your secret key. Place the private key in a safe place on a different system/device, such as a locked container or encrypted drive. It is the only safety you have to regain control to your keyring in case of, for example, a drive failure, theft or worse.}}<br />
<br />
=== Edit your key ===<br />
<br />
Running the {{ic|gpg --edit-key ''<user-id>''}} command will present a menu which enables you to do most of your key management related tasks.<br />
<br />
Some useful commands in the edit key sub menu:<br />
> passwd # change the passphrase<br />
> clean # compact any user ID that is no longer usable (e.g revoked or expired)<br />
> revkey # revoke a key<br />
> addkey # add a subkey to this key<br />
> expire # change the key expiration time<br />
<br />
Type {{ic|help}} in the edit key sub menu for more commands.<br />
<br />
{{Tip|If you have multiple email accounts you can add each one of them as an identity, using {{ic|adduid}} command. You can then set your favourite one as {{ic|primary}}.}}<br />
<br />
=== Exporting subkey ===<br />
<br />
If you plan to use the same key across multiple devices, you may want to strip out your master key and only keep the bare minimum encryption subkey on less secure systems.<br />
<br />
First, find out which subkey you want to export.<br />
<br />
$ gpg -K<br />
<br />
Select only that subkey to export.<br />
<br />
$ gpg -a --export-secret-subkeys [subkey id]! > /tmp/subkey.gpg<br />
<br />
{{Warning|If you forget to add the !, all of your subkeys will be exported.}}<br />
<br />
At this point you could stop, but it is most likely a good idea to change the passphrase as well. Import the key into a temporary folder. <br />
<br />
$ gpg --homedir /tmp/gpg --import /tmp/subkey.gpg<br />
$ gpg --homedir /tmp/gpg --edit-key ''<user-id>''<br />
> passwd<br />
> save<br />
$ gpg --homedir /tmp/gpg -a --export-secret-subkeys [subkey id]! > /tmp/subkey.altpass.gpg<br />
<br />
{{Note|You will get a warning that the master key was not available and the password was not changed, but that can safely be ignored as the subkey password was.}}<br />
<br />
At this point, you can now use {{ic|/tmp/subkey.altpass.gpg}} on your other devices.<br />
<br />
=== Rotating subkeys ===<br />
<br />
{{Warning|'''Never''' delete your expired or revoked subkeys unless you have a good reason. Doing so will cause you to lose the ability to decrypt files encrypted with the old subkey. Please '''only''' delete expired or revoked keys from other users to clean your keyring.}}<br />
<br />
If you have set your subkeys to expire after a set time, you can create new ones. Do this a few weeks in advance to allow others to update their keyring.<br />
<br />
{{Note|You do not need to create a new key simply because it is expired. You can extend the expiration date.}}<br />
<br />
Create new subkey (repeat for both signing and encrypting key)<br />
<br />
$ gpg --edit-key ''<user-id>''<br />
> addkey<br />
<br />
And answer the following questions it asks (see previous section for suggested settings).<br />
<br />
Save changes<br />
<br />
> save<br />
<br />
Update it to a keyserver.<br />
<br />
$ gpg --keyserver pgp.mit.edu --send-keys ''<user-id>''<br />
<br />
{{Note|Revoking expired subkeys is unnecessary and arguably bad form. If you are constantly revoking keys, it may cause others to lack confidence in you.}}<br />
<br />
== Signatures ==<br />
<br />
Signatures certify and timestamp documents. If the document is modified, verification of the signature will fail. Unlike encryption which uses public keys to encrypt a document, signatures are created with the user's private key. The recipient of a signed document then verifies the signature using the sender's public key.<br />
<br />
=== Sign a file ===<br />
<br />
To sign a file use the {{ic|--sign}} or {{ic|-s}} flag:<br />
<br />
$ gpg --output ''doc.sig'' --sign ''doc''<br />
<br />
The above also encrypts the file and stores it in binary format.<br />
<br />
=== Clearsign a file or message ===<br />
<br />
To sign a file without compressing it into binary format use:<br />
<br />
$ gpg --clearsign ''doc''<br />
<br />
This wraps the document into an ASCII-armored signature, but does not modify the document.<br />
<br />
=== Make a detached signature ===<br />
<br />
To create a separate signature file to be distributed separately from the document or file itself, use the {{ic|--detach-sig}} flag:<br />
<br />
$ gpg --output ''doc.sig'' --detach-sig ''doc''<br />
<br />
This method is often used in distributing software projects to allow users to verify that the program has not been modified by a third part.<br />
<br />
=== Verify a signature ===<br />
<br />
To verify a signature use the {{ic|--verify}} flag:<br />
<br />
$ gpg --verify ''doc.sig''<br />
<br />
where {{ic|''doc.sig''}} is the signature you wish to verify.<br />
<br />
To verify and decrypt a file at the same time, use the {{ic|--decrypt}} flag as you normally would in decrypting a file.<br />
<br />
If you are verifying a detached signature, both the file and the signature must be present when verifying. For example, to verify Arch Linux's latest iso you would do:<br />
<br />
$ gpg --verify ''archlinux-<version>-dual.iso.sig''<br />
<br />
where {{ic|''archlinux-<version>-dual.iso''}} must be located in the same directory.<br />
<br />
== gpg-agent ==<br />
<br />
''gpg-agent'' is mostly used as daemon to request and cache the password for the keychain. This is useful if GnuPG is used from an external program like a mail client.<br />
<br />
Starting with GnuPG 2.1.0 the use of ''gpg-agent'' is required. ''gpg-agent'' is started on-demand by the GnuPG tools, so there is usually no reason to start it manually.<br />
<br />
=== Configuration ===<br />
<br />
gpg-agent can be configured via {{ic|~/.gnupg/gpg-agent.conf}} file. The configuration options are listed in {{ic|man gpg-agent}}. For example you can change cache ttl for unused keys:<br />
<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
default-cache-ttl 3600<br />
}}<br />
<br />
{{Tip|To cache your passphrase for the whole session, please run the following command:<br />
$ /usr/lib/gnupg/gpg-preset-passphrase --preset XXXXXX<br />
<br />
where XXXX is the keygrip. You can get its value when running {{ic|gpg --with-keygrip -K}}. Passphrase will be stored until {{ic|gpg-agent}} is restarted. If you set up {{ic|default-cache-ttl}} value, it will take precedence.<br />
}}<br />
<br />
=== Reload the agent ===<br />
<br />
After changing the configuration, reload the agent using ''gpg-connect-agent'':<br />
<br />
$ gpg-connect-agent reloadagent /bye<br />
<br />
The command should print {{ic|OK}}.<br />
<br />
=== pinentry ===<br />
<br />
Finally, the agent needs to know how to ask the user for the password. This can be set in the gpg-agent configuration file.<br />
<br />
The default uses a gtk dialog. There are other options - see {{ic|info pinentry}}. To change the dialog implementation set {{ic|pinentry-program}} configuration option:<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
<br />
# PIN entry program<br />
# pinentry-program /usr/bin/pinentry-curses<br />
# pinentry-program /usr/bin/pinentry-qt<br />
# pinentry-program /usr/bin/pinentry-kwallet<br />
<br />
pinentry-program /usr/bin/pinentry-gtk-2<br />
}}<br />
<br />
{{Tip|For using {{ic|/usr/bin/pinentry-kwallet}} you have to install the {{Pkg|kwalletcli}} package.}}<br />
<br />
After making this change, reload the gpg-agent.<br />
<br />
=== Start gpg-agent with systemd user ===<br />
<br />
It is possible to use the [[Systemd/User]] facilities to start the agent.<br />
<br />
Create a systemd unit file:<br />
<br />
{{hc|~/.config/systemd/user/gpg-agent.service|2=<br />
[Unit]<br />
Description=GnuPG private key agent<br />
IgnoreOnIsolate=true<br />
<br />
[Service]<br />
Type=forking<br />
ExecStart=/usr/bin/gpg-agent --daemon<br />
Restart=on-abort<br />
<br />
[Install]<br />
WantedBy=default.target<br />
}}<br />
<br />
{{Note|If you use non-default value for the [[#GNUPGHOME]] environment variable, you need to pass it to the service. See [[systemd/User#Environment variables]] for details.}}<br />
<br />
=== Unattended passphrase ===<br />
<br />
Starting with GnuPG 2.1.0 the use of gpg-agent and pinentry is required, which may break backwards compatibility for passphrases piped in from STDIN using the {{ic|--passphrase-fd 0}} commandline option. In order to have the same type of functionality as the older releases two things must be done:<br />
<br />
First, edit the gpg-agent configuration to allow ''loopback'' pinentry mode:<br />
<br />
{{hc|1=~/.gnupg/gpg-agent.conf|2=<br />
allow-loopback-pinentry<br />
}}<br />
<br />
Restart the gpg-agent process if it is running to let the change take effect.<br />
<br />
Second, either the application needs to be updated to include a commandline parameter to use loopback mode like so:<br />
<br />
$ gpg --pinentry-mode loopback ...<br />
<br />
...or if this is not possible, add the option to the configuration:<br />
<br />
{{hc|1=~/.gnupg/gpg.conf|2=<br />
pinentry-mode loopback<br />
}}<br />
<br />
{{Note|The upstream author indicates setting {{ic|pinentry-mode loopback}} in {{ic|gpg.conf}} may break other usage, using the commandline option should be preferred if at all possible. [https://bugs.g10code.com/gnupg/issue1772]}}<br />
<br />
=== SSH agent ===<br />
<br />
''gpg-agent'' has OpenSSH agent emulation. If you already use the GnuPG suite, you might consider using its agent to also cache your SSH keys. Additionally, some users may prefer the PIN entry dialog GnuPG agent provides as part of its passphrase management.<br />
<br />
To start using GnuPG agent for your SSH keys, enable SSH support in the {{ic|~/.gnupg/gpg-agent.conf}} file:<br />
<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
enable-ssh-support<br />
}}<br />
<br />
Next, make sure that ''gpg-agent'' is always started. Use either the [[#Start gpg-agent with systemd user|systemd user service]] or add the following to your {{ic|.bashrc}} file:<br />
<br />
{{hc|~/.bashrc|<nowiki><br />
# Start the gpg-agent if not already running<br />
if ! pgrep -x -u "${USER}" gpg-agent >/dev/null 2>&1; then<br />
gpg-connect-agent /bye >/dev/null 2>&1<br />
fi<br />
</nowiki>}}<br />
<br />
Then set {{ic|SSH_AUTH_SOCK}} so that SSH will use ''gpg-agent'' instead of ''ssh-agent'':<br />
<br />
{{hc|~/.bashrc|<nowiki><br />
# Set SSH to use gpg-agent<br />
unset SSH_AGENT_PID<br />
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then<br />
export SSH_AUTH_SOCK="${HOME}/.gnupg/S.gpg-agent.ssh"<br />
fi<br />
</nowiki>}}<br />
<br />
Also set the GPG TTY and refresh the TTY in case user has switched into an X session. Example:<br />
<br />
{{Expansion|Not clear why this is necessary (even tha man page does not explain it).}}<br />
<br />
{{hc|~/.bashrc|<nowiki><br />
# Set GPG TTY<br />
export GPG_TTY=$(tty)<br />
<br />
# Refresh gpg-agent tty in case user switches into an X session<br />
gpg-connect-agent updatestartuptty /bye >/dev/null<br />
</nowiki>}}<br />
<br />
Once ''gpg-agent'' is running you can use ''ssh-add'' to approve keys, following the same steps as for [[SSH keys#ssh-agent|ssh-agent]]. The list of approved keys is stored in the {{ic|~/.gnupg/sshcontrol}} file. Once your key is approved, you will get a ''pinentry'' dialog every time your passphrase is needed. You can control passphrase caching in the {{ic|~/.gnupg/gpg-agent.conf}} file. The following example would have ''gpg-agent'' cache your keys for 3 hours:<br />
<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
default-cache-ttl-ssh 10800<br />
}}<br />
<br />
== Smartcards ==<br />
<br />
GnuPG uses ''scdaemon'' as an interface to your smartcard reader, please refer to the [[man page]] for details.<br />
<br />
=== GnuPG only setups ===<br />
<br />
{{Note| To allow scdaemon direct access to USB smarcard readers the optional dependency {{Pkg|libusb-compat}} have to be installed}}<br />
<br />
If you do not plan to use other cards but those based on GnuPG, you should check the {{Ic|reader-port}} parameter in {{ic|~/.gnupg/scdaemon.conf}}. The value '0' refers to the first available serial port reader and a value of '32768' (default) refers to the first USB reader.<br />
<br />
=== GnuPG with PSCD-Lite ===<br />
<br />
{{Note|{{Pkg|pcsclite}} and {{Pkg|ccid}} have to be installed, and the contained [[systemd#Using units|systemd]] service {{ic|pcscd.service}} has to be running, or the socket {{ic|pscd.socket}} has to be listening.}}<br />
<br />
PSCD-Lite is a daemon which handles access to smartcard (SCard API). If GnuPG's scdaemon fails to connect the smartcard directly (e.g. by using its integrated CCID support), it will fallback and try to find a smartcard using the PSCD-Lite driver.<br />
<br />
==== Always use PSCD-Light ====<br />
<br />
If you are using any smartcard with an opensc driver (e.g.: ID cards from some countries) you should pay some attention to GnuPG configuration. Out of the box you might receive a message like this when using {{Ic|gpg --card-status}}<br />
<br />
gpg: selecting openpgp failed: ec=6.108<br />
<br />
By default, scdaemon will try to connect directly to the device. This connection will fail if the reader is being used by another process. For example: the pcscd daemon used by OpenSC. To cope with this situation we should use the same underlying driver as opensc so they can work well together. In order to point scdaemon to use pcscd you should remove {{Ic|reader-port}} from {{ic|~/.gnupg/scdaemon.conf}}, specify the location to {{ic|libpcsclite.so}} library and disable ccid so we make sure that we use pcscd:<br />
<br />
{{hc|~/.gnupg/scdaemon.conf|<nowiki><br />
pcsc-driver /usr/lib/libpcsclite.so<br />
card-timeout 5<br />
disable-ccid<br />
</nowiki>}}<br />
<br />
Please check {{Ic|man scdaemon}} if you do not use OpenSC.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Different algorithm ===<br />
<br />
You may want to use stronger algorithms:<br />
<br />
{{hc|~/.gnupg/gpg.conf|<br />
...<br />
<br />
personal-digest-preferences SHA512<br />
cert-digest-algo SHA512<br />
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed<br />
personal-cipher-preferences TWOFISH CAMELLIA256 AES 3DES<br />
}}<br />
<br />
In the latest version of GnuPG, the default algorithms used are SHA256 and AES, both of which are secure enough for most people. However, if you are using a version of GnuPG older than 2.1, or if you want an even higher level of security, then you should follow the above step.<br />
<br />
=== Encrypt a password ===<br />
<br />
It can be useful to encrypt some password, so it will not be written in clear on a configuration file. A good example is your email password.<br />
<br />
First create a file with your password. You '''need''' to leave '''one''' empty line after the password, otherwise gpg will return an error message when evaluating the file.<br />
<br />
Then run:<br />
<br />
$ gpg -e -a -r ''<user-id>'' ''your_password_file''<br />
<br />
{{ic|-e}} is for encrypt, {{ic|-a}} for armor (ASCII output), {{ic|-r}} for recipient user ID.<br />
<br />
You will be left with a new {{ic|''your_password_file''.asc}} file.<br />
<br />
=== Revoking a key ===<br />
<br />
{{Warning|<br />
*Anybody having access to your revocation certificate can revoke your key, rendering it useless.<br />
*Key revocation should only be performed if your key is compromised or lost, or you forget your passphrase.}}<br />
<br />
Revocation certificates are automatically generated for newly generated keys, although one can be generated manually by the user later. These are located at {{ic|~/.gnupg/openpgp-revocs.d/}}. The filename of the certificate is the fingerprint of the key it will revoke.<br />
<br />
To revoke your key, simply import the revocation certificate:<br />
<br />
$ gpg --import ''<fingerprint>''.rev<br />
<br />
Now update the keyserver:<br />
<br />
$ gpg --keyserver subkeys.pgp.net --send ''<userid>''<br />
<br />
=== Change trust model ===<br />
<br />
By default GnuPG uses the [[Wikipedia::Web of Trust|Web of Trust]] as the trust model. You can change this to [[Wikipedia::Trust on First|Trust on First]] Use by adding {{ic|1=--trust-model=tofu}} when adding a key or adding this option to your GnuPG configuration file. More details are in [https://lists.gnupg.org/pipermail/gnupg-devel/2015-October/030341.html this email to the GnuPG list].<br />
<br />
=== Hide all recipient id's ===<br />
<br />
By default the recipient's key ID is in the encrypted message. This can be removed at encryption time for a recipient by using {{ic|hidden-recipient ''<user-id>''}}. To remove it for all recipients add {{ic|throw-keyids}} to your configuration file. This helps to hide the receivers of the message and is a limited countermeasure against traffic analysis. (Using a little social engineering anyone who is able to decrypt the message can check whether one of the other recipients is the one he suspects.) On the receiving side, it may slow down the decryption process because all available secret keys must be tried (''e.g.'' with {{ic|--try-secret-key ''<user-id>''}}).<br />
<br />
=== Using caff for keysigning parties ===<br />
<br />
To allow users to validate keys on the keyservers and in their keyrings (i.e. make sure they are from whom they claim to be), PGP/GPG uses he [[Wikipedia::Web of Trust|Web of Trust]]. Keysigning parties allow users to get together in physical location to validate keys. The [[Wikipedia:Zimmermann–Sassaman key-signing protocol|Zimmermann-Sassaman]] key-signing protocol is a way of making these very effective. [http://www.cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html Here] you will find a how-to article.<br />
<br />
For an easier process of signing keys and sending signatures to the owners after a keysigning party, you can use the tool ''caff''. It can be installed from the AUR with the package {{AUR|caff-svn}} or bundled together with other useful tools in the package {{AUR|signing-party-svn}}{{Broken package link|{{aur-mirror|signing-party-svn}}}}.<br />
Either way, there will be a lot of dependencies installing from the AUR. Alternatively you can install them from CPAN with<br />
cpanm Any::Moose<br />
cpanm GnuPG::Interface<br />
<br />
To send the signatures to their owners you need a working [[Wikipedia:Message transfer agent|MTA]]. If you do not have already one, install [[msmtp]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Not enough random bytes available ===<br />
When generating a key, gpg can run into this error:<br />
Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy!<br />
To check the available entropy, check the kernel parameters:<br />
cat /proc/sys/kernel/random/entropy_avail<br />
A healthy Linux system with a lot of entropy available will have return close to the full 4,096 bits of entropy. If the value returned is less than 200, the system is running low on entropy. <br />
<br />
To solve it, remember you do not often need to create keys and best just do what the message suggests (e.g. create disk activity, move the mouse, edit the wiki - all will create entropy). If that does not help, check which service is using up the entropy and consider stopping it for the time. If that is no alternative, see [[Random number generation#Faster alternatives]].<br />
<br />
=== su ===<br />
<br />
When using {{Ic|pinentry}}, you must have the proper permissions of the terminal device (e.g. {{Ic|/dev/tty1}}) in use. However, with ''su'' (or ''sudo''), the ownership stays with the original user, not the new one. This means that pinentry will fail, even as root. The fix is to change the permissions of the device at some point before the use of pinentry (i.e. using gpg with an agent). If doing gpg as root, simply change the ownership to root right before using gpg:<br />
<br />
chown root /dev/ttyN # where N is the current tty<br />
<br />
and then change it back after using gpg the first time. The equivalent is likely to be true with {{Ic|/dev/pts/}}.<br />
<br />
{{Note|The owner of tty ''must'' match with the user for which pinentry is running. Being part of the group {{Ic|tty}} '''is not''' enough.}}<br />
<br />
=== Agent complains end of file ===<br />
<br />
The default pinentry program is pinentry-gtk-2, which needs a DBus session bus to run properly. See [[General troubleshooting#Session permissions]] for details.<br />
<br />
Alternatively, you can use {{ic|pinentry-qt}}. See [[#pinentry]].<br />
<br />
=== KGpg configuration permissions ===<br />
<br />
There have been issues with {{Pkg|kdeutils-kgpg}} being able to access the {{ic|~/.gnupg/}} options. One issue might be a result of a deprecated ''options'' file, see the [https://bugs.kde.org/show_bug.cgi?id=290221 bug] report.<br />
<br />
Another user reported that ''KGpg'' failed to start until the {{ic|~/.gnupg}} folder is set to {{ic|drwxr-xr-x}} permissions. If you require this work-around, ensure that the directory contents retain {{ic|-rw-------}} permissions! Further, report it as a bug to the [https://bugs.kde.org/buglist.cgi?quicksearch=kgpg developers].<br />
<br />
=== Conflicts between gnome-keyring and gpg-agent ===<br />
<br />
{{Accuracy|See [[#GPG_AGENT_INFO]]}}<br />
<br />
While the Gnome keyring implements a GPG agent component, as of GnuPG version 2.1, GnuPG ignores the {{ic|GPG_AGENT_INFO}} environment variable, so that Gnome keyring can no longer be used as a GPG agent.<br />
<br />
However, since version 0.9.6 the package {{Pkg|pinentry}} provides the {{Ic|pinentry-gnome3}} program. You may set the following option in your {{Ic|gpg-agent.conf}} file<br />
pinentry-program /usr/bin/pinentry-gnome3<br />
in order to make use of that pinentry program.<br />
<br />
Since version 0.9.2 all pinentry programs can be configured to optionally save a passphrase with libsecret. For example, when the user is asked for a passphrase via {{Ic|pinentry-gnome3}}, a checkbox is shown whether to save the passphrase using a password manager. Unfortunately, the package {{Pkg|pinentry}} does not have this feature enabled (see {{Bug|46059}} for the reasons). You may use {{AUR|pinentry-libsecret}} as a replacement for it, which has support for libsecret enabled.<br />
<br />
=== mutt and gpg ===<br />
<br />
To be asked for your GnuPG password only once per session as of GnuPG 2.1, see [https://bbs.archlinux.org/viewtopic.php?pid=1490821#p1490821 this forum thread].<br />
<br />
=== "Lost" keys, upgrading to gnupg version 2.1 ===<br />
<br />
When {{ic|gpg --list-keys}} fails to show keys that used to be there, and applications complain about missing or invalid keys, some keys may not have been migrated to the new format.<br />
<br />
Please read [http://jo-ke.name/wp/?p=111 GnuPG invalid packet workaround]. Basically, it says that there is a bug with keys in the old {{ic|pubring.gpg}} and {{ic|secring.gpg}} files, which have now been superseded by the new {{ic|pubring.kbx}} file and the {{ic|private-keys-v1.d/}} subdirectory and files. Your missing keys can be recovered with the following commnads:<br />
<br />
$ cd<br />
$ cp -r .gnupg gnupgOLD<br />
$ gpg --export-ownertrust > otrust.txt<br />
$ gpg --import .gnupg/pubring.gpg<br />
$ gpg --import-ownertrust otrust.txt<br />
$ gpg --list-keys<br />
<br />
=== gpg hanged for all keyservers (when trying to receive keys) ===<br />
<br />
If gpg hanged with a certain keyserver when trying to receive keys, you might need to kill dirmngr in order to get access to other keyservers which are actually working, otherwise it might keeping hanging for all of them.<br />
<br />
=== Smartcard not detected ===<br />
<br />
Your user might not have the permission to access the smartcard which results in a {{ic|card error}} to be thrown, even though the card is correctly set up and inserted.<br />
<br />
One possible solution is to add a new group {{ic|scard}} including the users who need access to the smartcard.<br />
<br />
Then use an [[Udev#Writing_udev_rules|udev]] rule, similar to the following:<br />
{{hc|/etc/udev/rules.d/71-gnupg-ccid.rules|<nowiki><br />
ACTION=="add", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="1050", ENV{ID_MODEL_ID}=="0116|0111", MODE="660", GROUP="scard"<br />
</nowiki>}}<br />
One needs to adapt VENDOR and MODEL according to the {{ic|lsusb}} output, the above example is for a YubikeyNEO.<br />
<br />
== See also ==<br />
<br />
* [https://gnupg.org/ GNU Privacy Guard Homepage]<br />
* [https://fedoraproject.org/wiki/Creating_GPG_Keys Creating GPG Keys (Fedora)]<br />
* [https://wiki.debian.org/Subkeys OpenPGP subkeys in Debian]<br />
* [http://blog.sanctum.geek.nz/series/linux-crypto/ A more comprehensive gpg Tutorial]<br />
* [https://help.riseup.net/en/security/message-security/openpgp/gpg-best-practices gpg.conf recommendations and best practices]<br />
* [https://github.com/ioerror/torbirdy/blob/master/gpg.conf Torbirdy gpg.conf]<br />
* [https://www.reddit.com/r/GPGpractice/ /r/GPGpractice - a subreddit to practice using GnuPG.]</div>Ritkahttps://wiki.archlinux.org/index.php?title=GnuPG&diff=434679GnuPG2016-05-11T18:11:46Z<p>Ritka: /* Encrypt and decrypt */ Added short notice on public-key crypto with link to wikipedia at the beginning. That shall clarify for beginners whats gonna happen in the following paragraphs</p>
<hr />
<div>[[Category:Encryption]]<br />
[[es:GnuPG]]<br />
[[ja:GnuPG]]<br />
[[ru:GnuPG]]<br />
[[zh-cn:GnuPG]]<br />
{{Related articles start}}<br />
{{Related|pacman/Package signing}}<br />
{{Related|Disk encryption}}<br />
{{Related|List of applications/Security#Encryption, signing, steganography}}<br />
{{Related articles end}}<br />
<br />
According to the [http://www.gnupg.org official website]:<br />
<br />
:GnuPG is a complete and free implementation of the OpenPGP standard as defined by RFC4880 (also known as [[Wikipedia:PGP|PGP]]). GnuPG allows to encrypt and sign your data and communication, features a versatile key management system as well as access modules for all kinds of public key directories. GnuPG, also known as GPG, is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries are available. Version 2 of GnuPG also provides support for S/MIME and Secure Shell (ssh).<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|gnupg}} package.<br />
<br />
This will also install {{Pkg|pinentry}}, a collection of simple PIN or passphrase entry dialogs which GnuPG uses for passphrase entry. Which ''pinentry'' dialog is used is determined by the symbolic link {{ic|/usr/bin/pinentry}}, which by default points to {{ic|/usr/bin/pinentry-gtk-2}}.<br />
<br />
If you want to use a graphical frontend or program that integrates with GnuPG, see [[List of applications/Security#Encryption, signing, steganography]].<br />
<br />
== Configuration ==<br />
<br />
=== Directory location ===<br />
{{ic|$GNUPGHOME}} is used by GnuPG to point to the directory where its configuration files are stored. By default {{ic|$GNUPGHOME}} is not set and your {{ic|$HOME}} is used instead; thus, you will find a {{ic|~/.gnupg}} directory right after installation. <br />
<br />
To change the default location, either run gpg this way {{ic|$ gpg --homedir ''path/to/file''}} or set {{ic|GNUPGHOME}} in one of your regular [[startup files]].<br />
<br />
=== Configuration files ===<br />
<br />
The default configuration files are {{ic|~/.gnupg/gpg.conf}} and {{ic|~/.gnupg/dirmngr.conf}}. <br />
<br />
By default, the gnupg directory has its [[permissions]] set to {{ic|700}} and the files it contains have their permissions set to {{ic|600}}. Only the owner of the directory has permission to read, write, and access the files. This is for security purposes and should not be changed. In case this directory or any file inside it does not follow this security measure, you will get warnings about unsafe file and home directory permissions.<br />
<br />
Append to these files any long options you want. Do not write the two dashes, but simply the name of the option and required arguments. You will find skeleton files in {{ic|/usr/share/gnupg}}. These files are copied to {{ic|~/.gnupg}} the first time gpg is run if they do not exist there. Other examples are found in [[#See also]].<br />
<br />
Additionally, [[pacman]] uses a different set of configuration files for package signature verification. See [[Pacman/Package signing]] for details.<br />
<br />
=== Default options for new users ===<br />
<br />
If you want to setup some default options for new users, put configuration files in {{ic|/etc/skel/.gnupg/}}. When the new user is added in system, files from here will be copied to its GnuPG home directory. There is also a simple script called ''addgnupghome'' which you can use to create new GnuPG home directories for existing users:<br />
<br />
# addgnupghome user1 user2<br />
<br />
This will add the respective {{ic|/home/user1/.gnupg}} and {{ic|/home/user2/.gnupg}} and copy the files from the skeleton directory to it. Users with existing GnuPG home directory are simply skipped.<br />
<br />
== Usage ==<br />
<br />
{{Note|Whenever a ''{{ic|<user-id>}}'' is required in a command, it can be specified with your key ID, fingerprint, a part of your name or email address, etc. GnuPG is flexible on this.<br />
}}<br />
<br />
=== Create key pair ===<br />
<br />
Generate a key pair by typing in a terminal:<br />
<br />
$ gpg --full-gen-key<br />
<br />
{{Tip|Use the {{ic|--expert}} option for getting alternative ciphers like [[wikipedia:Elliptic_curve_cryptography|ECC]].}}<br />
<br />
The command will prompt for answers to several questions. For general use most people will want: <br />
<br />
* the RSA (sign only) and a RSA (encrypt only) key.<br />
* a keysize of the default value (2048). A larger keysize of 4096 "gives us almost nothing, while costing us quite a lot"[https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096].<br />
* an expiration date. A period of a year is good enough for the average user. This way even if access is lost to the keyring, it will allow others to know that it is no longer valid. Later, if necessary, the expiration date can be extended without having to re-issue a new key.<br />
* your name and email address. You can add multiple identities to the same key later (''e.g.'', if you have multiple email addresses you want to associate with this key).<br />
* ''no'' optional comment. Since the semantics of the comment field are [https://lists.gnupg.org/pipermail/gnupg-devel/2015-July/030150.html not well-defined], it has limited value for identification.<br />
* [[Security#Choosing_secure_passwords|a secure passphrase]].<br />
<br />
{{Note|The name and email address you enter here will be seen by anybody who imports your key.}}<br />
<br />
=== List keys ===<br />
<br />
To list keys in your public key ring:<br />
<br />
$ gpg --list-keys<br />
<br />
To list keys in your secret key ring:<br />
<br />
$ gpg --list-secret-keys<br />
<br />
=== Export your public key ===<br />
<br />
In order for others to send encrypted messages to you, they need your public key.<br />
<br />
To generate an ASCII version of your public key (''e.g.'' to distribute it by e-mail):<br />
<br />
$ gpg --armor --output ''public.key'' --export ''<user-id>''<br />
<br />
Alternatively, or in addition, you can [[#Use a keyserver]] to share your key. <br />
<br />
{{Tip|Add {{ic|--no-emit-version}} to avoid printing the version number, or add the corresponding setting to your configuration file.}}<br />
<br />
=== Import a key ===<br />
<br />
In order to encrypt messages to others, as well as verify their signatures, you need their public key. To import a public key with file name {{ic|''public.key''}} to your public key ring:<br />
<br />
$ gpg --import ''public.key''<br />
<br />
Alternatively, [[#Use a keyserver]] to find a public key.<br />
<br />
=== Use a keyserver ===<br />
<br />
You can register your key with a public PGP key server, so that others can retrieve your key without having to contact you directly:<br />
<br />
$ gpg --send-keys ''<key-id>''<br />
<br />
To find out details of a key on the keyserver, without importing it, do:<br />
<br />
$ gpg --search-keys ''<key-id>''<br />
<br />
To import a key from a key server:<br />
<br />
$ gpg --recv-keys ''<key-id>''<br />
<br />
{{Warning|Anyone can send keys to a keyserver, so you should not trust that the key you download actually belongs to the individual listed. You should verify the authenticity of the retrieved public key by comparing its fingerprint with one that the owner published on an independent source, such as their own blog or website, or contacting them by email, over the phone or in person. Using multiple authentication sources will increase the level of trust you can give to the downloaded key. See [[Wikipedia:Public key fingerprint]] for more information.}}<br />
<br />
{{Tip|<br />
* Adding {{ic|keyserver-options auto-key-retrieve}} to {{ic|gpg.conf}} will automatically fetch keys from the key server as needed.<br />
* An alternative key server is {{ic|pool.sks-keyservers.net}} and can be specified with {{ic|keyserver}} in {{ic|dirmngr.conf}}.; see also [[wikipedia:Key server (cryptographic)#Keyserver examples]].<br />
* You can connect to the keyserver over [[Tor]] using {{ic|--use-tor}}. {{ic|hkp://jijrk5u4osbsr34t5.onion}} is the onion address for the sks-keyservers pool. [https://gnupg.org/blog/20151224-gnupg-in-november-and-december.html See this GnuPG blog post] for more information.<br />
* You can connect to a keyserver using a proxy by setting the {{ic|http_proxy}} environment variable and setting {{ic|honor-http-proxy}} in {{ic|dirmngr.conf}}. Alternatively, set {{ic|http-proxy ''host[:port]''}} in {{ic|dirmngr.conf}}, overriding the {{ic|http_proxy}} environment variable.}}<br />
<br />
=== Encrypt and decrypt ===<br />
<br />
gpg's main usage is public-key cryptography (see [[Wikipedia:Public-key cryptography]]). That means, you usually use a users public key to encrypt files and you use your private key to decrypt them.<br />
<br />
When encrypting or decrypting it is possible to have more than one private key in use. If this occurs you need to select the active key by using the option {{ic|-u ''<user-id>''}} or {{ic|--local-user ''<user-id>''}}.<br />
<br />
To encrypt a file named {{ic|''doc''}} using ASCII armor (suitable for copying and pasting a message in text format), use:<br />
<br />
$ gpg --encrypt --armor ''doc''<br />
<br />
If you want to just encrypt a file, exclude {{ic|--armor}}.<br />
<br />
{{Tip|<br />
* If you want to change recipient this can be done by the option {{ic|-r ''<user-id>''}} (or {{ic|--recipient ''<user-id>''}}).<br />
* Add {{ic|-R ''<user-id>''}} or {{ic|--hidden-recipient ''<user-id>''}} instead of {{ic|--recipient}} to not put the recipient key IDs in the encrypted message. This helps to hide the receivers of the message and is a limited countermeasure against traffic analysis.<br />
* Add {{ic|--no-emit-version}} to avoid printing the version number, or add the corresponding setting to your configuration file.}}<br />
<br />
{{Note|You can use gnupg to encrypt your sensitive documents, but only individual files at a time. If you want to encrypt directories or a whole file-system you should consider using [[TrueCrypt]] or [[EncFS]], though you can always tarball various files and then encrypt them.}}<br />
<br />
To decrypt a file encrypted with your public key, use:<br />
<br />
$ gpg --decrypt ''doc.asc''<br />
<br />
You will be prompted to enter your passphrase.<br />
<br />
== Key maintenance ==<br />
<br />
=== Backup your private key ===<br />
<br />
To backup your private key do the following:<br />
<br />
$ gpg --export-secret-keys --armor ''<user-id>'' > ''privkey.asc''<br />
<br />
Note that ''gpg'' release 2.1 changed default behaviour so that the above command enforces a passphrase protection, even if you deliberately chose not to use one on key creation. This is because otherwise anyone who gains access to the above exported file would be able to encrypt and sign documents as if they were you ''without'' needing to know your passphrase. <br />
<br />
{{Warning|The passphrase is usually the weakest link in protecting your secret key. Place the private key in a safe place on a different system/device, such as a locked container or encrypted drive. It is the only safety you have to regain control to your keyring in case of, for example, a drive failure, theft or worse.}}<br />
<br />
=== Edit your key ===<br />
<br />
Running the {{ic|gpg --edit-key ''<user-id>''}} command will present a menu which enables you to do most of your key management related tasks.<br />
<br />
Some useful commands in the edit key sub menu:<br />
> passwd # change the passphrase<br />
> clean # compact any user ID that is no longer usable (e.g revoked or expired)<br />
> revkey # revoke a key<br />
> addkey # add a subkey to this key<br />
> expire # change the key expiration time<br />
<br />
Type {{ic|help}} in the edit key sub menu for more commands.<br />
<br />
{{Tip|If you have multiple email accounts you can add each one of them as an identity, using {{ic|adduid}} command. You can then set your favourite one as {{ic|primary}}.}}<br />
<br />
=== Exporting subkey ===<br />
<br />
If you plan to use the same key across multiple devices, you may want to strip out your master key and only keep the bare minimum encryption subkey on less secure systems.<br />
<br />
First, find out which subkey you want to export.<br />
<br />
$ gpg -K<br />
<br />
Select only that subkey to export.<br />
<br />
$ gpg -a --export-secret-subkeys [subkey id]! > /tmp/subkey.gpg<br />
<br />
{{Warning|If you forget to add the !, all of your subkeys will be exported.}}<br />
<br />
At this point you could stop, but it is most likely a good idea to change the passphrase as well. Import the key into a temporary folder. <br />
<br />
$ gpg --homedir /tmp/gpg --import /tmp/subkey.gpg<br />
$ gpg --homedir /tmp/gpg --edit-key ''<user-id>''<br />
> passwd<br />
> save<br />
$ gpg --homedir /tmp/gpg -a --export-secret-subkeys [subkey id]! > /tmp/subkey.altpass.gpg<br />
<br />
{{Note|You will get a warning that the master key was not available and the password was not changed, but that can safely be ignored as the subkey password was.}}<br />
<br />
At this point, you can now use {{ic|/tmp/subkey.altpass.gpg}} on your other devices.<br />
<br />
=== Rotating subkeys ===<br />
<br />
{{Warning|'''Never''' delete your expired or revoked subkeys unless you have a good reason. Doing so will cause you to lose the ability to decrypt files encrypted with the old subkey. Please '''only''' delete expired or revoked keys from other users to clean your keyring.}}<br />
<br />
If you have set your subkeys to expire after a set time, you can create new ones. Do this a few weeks in advance to allow others to update their keyring.<br />
<br />
{{Note|You do not need to create a new key simply because it is expired. You can extend the expiration date.}}<br />
<br />
Create new subkey (repeat for both signing and encrypting key)<br />
<br />
$ gpg --edit-key ''<user-id>''<br />
> addkey<br />
<br />
And answer the following questions it asks (see previous section for suggested settings).<br />
<br />
Save changes<br />
<br />
> save<br />
<br />
Update it to a keyserver.<br />
<br />
$ gpg --keyserver pgp.mit.edu --send-keys ''<user-id>''<br />
<br />
{{Note|Revoking expired subkeys is unnecessary and arguably bad form. If you are constantly revoking keys, it may cause others to lack confidence in you.}}<br />
<br />
== Signatures ==<br />
<br />
Signatures certify and timestamp documents. If the document is modified, verification of the signature will fail. Unlike encryption which uses public keys to encrypt a document, signatures are created with the user's private key. The recipient of a signed document then verifies the signature using the sender's public key.<br />
<br />
=== Sign a file ===<br />
<br />
To sign a file use the {{ic|--sign}} or {{ic|-s}} flag:<br />
<br />
$ gpg --output ''doc.sig'' --sign ''doc''<br />
<br />
The above also encrypts the file and stores it in binary format.<br />
<br />
=== Clearsign a file or message ===<br />
<br />
To sign a file without compressing it into binary format use:<br />
<br />
$ gpg --clearsign ''doc''<br />
<br />
This wraps the document into an ASCII-armored signature, but does not modify the document.<br />
<br />
=== Make a detached signature ===<br />
<br />
To create a separate signature file to be distributed separately from the document or file itself, use the {{ic|--detach-sig}} flag:<br />
<br />
$ gpg --output ''doc.sig'' --detach-sig ''doc''<br />
<br />
This method is often used in distributing software projects to allow users to verify that the program has not been modified by a third part.<br />
<br />
=== Verify a signature ===<br />
<br />
To verify a signature use the {{ic|--verify}} flag:<br />
<br />
$ gpg --verify ''doc.sig''<br />
<br />
where {{ic|''doc.sig''}} is the signature you wish to verify.<br />
<br />
To verify and decrypt a file at the same time, use the {{ic|--decrypt}} flag as you normally would in decrypting a file.<br />
<br />
If you are verifying a detached signature, both the file and the signature must be present when verifying. For example, to verify Arch Linux's latest iso you would do:<br />
<br />
$ gpg --verify ''archlinux-<version>-dual.iso.sig''<br />
<br />
where {{ic|''archlinux-<version>-dual.iso''}} must be located in the same directory.<br />
<br />
== gpg-agent ==<br />
<br />
''gpg-agent'' is mostly used as daemon to request and cache the password for the keychain. This is useful if GnuPG is used from an external program like a mail client.<br />
<br />
Starting with GnuPG 2.1.0 the use of ''gpg-agent'' is required. ''gpg-agent'' is started on-demand by the GnuPG tools, so there is usually no reason to start it manually.<br />
<br />
=== Configuration ===<br />
<br />
gpg-agent can be configured via {{ic|~/.gnupg/gpg-agent.conf}} file. The configuration options are listed in {{ic|man gpg-agent}}. For example you can change cache ttl for unused keys:<br />
<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
default-cache-ttl 3600<br />
}}<br />
<br />
{{Tip|To cache your passphrase for the whole session, please run the following command:<br />
$ /usr/lib/gnupg/gpg-preset-passphrase --preset XXXXXX<br />
<br />
where XXXX is the keygrip. You can get its value when running {{ic|gpg --with-keygrip -K}}. Passphrase will be stored until {{ic|gpg-agent}} is restarted. If you set up {{ic|default-cache-ttl}} value, it will take precedence.<br />
}}<br />
<br />
=== Reload the agent ===<br />
<br />
After changing the configuration, reload the agent using ''gpg-connect-agent'':<br />
<br />
$ gpg-connect-agent reloadagent /bye<br />
<br />
The command should print {{ic|OK}}.<br />
<br />
=== pinentry ===<br />
<br />
Finally, the agent needs to know how to ask the user for the password. This can be set in the gpg-agent configuration file.<br />
<br />
The default uses a gtk dialog. There are other options - see {{ic|info pinentry}}. To change the dialog implementation set {{ic|pinentry-program}} configuration option:<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
<br />
# PIN entry program<br />
# pinentry-program /usr/bin/pinentry-curses<br />
# pinentry-program /usr/bin/pinentry-qt<br />
# pinentry-program /usr/bin/pinentry-kwallet<br />
<br />
pinentry-program /usr/bin/pinentry-gtk-2<br />
}}<br />
<br />
{{Tip|For using {{ic|/usr/bin/pinentry-kwallet}} you have to install the {{Pkg|kwalletcli}} package.}}<br />
<br />
After making this change, reload the gpg-agent.<br />
<br />
=== Start gpg-agent with systemd user ===<br />
<br />
It is possible to use the [[Systemd/User]] facilities to start the agent.<br />
<br />
Create a systemd unit file:<br />
<br />
{{hc|~/.config/systemd/user/gpg-agent.service|2=<br />
[Unit]<br />
Description=GnuPG private key agent<br />
IgnoreOnIsolate=true<br />
<br />
[Service]<br />
Type=forking<br />
ExecStart=/usr/bin/gpg-agent --daemon<br />
Restart=on-abort<br />
<br />
[Install]<br />
WantedBy=default.target<br />
}}<br />
<br />
{{Note|If you use non-default value for the [[#GNUPGHOME]] environment variable, you need to pass it to the service. See [[systemd/User#Environment variables]] for details.}}<br />
<br />
=== Unattended passphrase ===<br />
<br />
Starting with GnuPG 2.1.0 the use of gpg-agent and pinentry is required, which may break backwards compatibility for passphrases piped in from STDIN using the {{ic|--passphrase-fd 0}} commandline option. In order to have the same type of functionality as the older releases two things must be done:<br />
<br />
First, edit the gpg-agent configuration to allow ''loopback'' pinentry mode:<br />
<br />
{{hc|1=~/.gnupg/gpg-agent.conf|2=<br />
allow-loopback-pinentry<br />
}}<br />
<br />
Restart the gpg-agent process if it is running to let the change take effect.<br />
<br />
Second, either the application needs to be updated to include a commandline parameter to use loopback mode like so:<br />
<br />
$ gpg --pinentry-mode loopback ...<br />
<br />
...or if this is not possible, add the option to the configuration:<br />
<br />
{{hc|1=~/.gnupg/gpg.conf|2=<br />
pinentry-mode loopback<br />
}}<br />
<br />
{{Note|The upstream author indicates setting {{ic|pinentry-mode loopback}} in {{ic|gpg.conf}} may break other usage, using the commandline option should be preferred if at all possible. [https://bugs.g10code.com/gnupg/issue1772]}}<br />
<br />
=== SSH agent ===<br />
<br />
''gpg-agent'' has OpenSSH agent emulation. If you already use the GnuPG suite, you might consider using its agent to also cache your SSH keys. Additionally, some users may prefer the PIN entry dialog GnuPG agent provides as part of its passphrase management.<br />
<br />
To start using GnuPG agent for your SSH keys, enable SSH support in the {{ic|~/.gnupg/gpg-agent.conf}} file:<br />
<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
enable-ssh-support<br />
}}<br />
<br />
Next, make sure that ''gpg-agent'' is always started. Use either the [[#Start gpg-agent with systemd user|systemd user service]] or add the following to your {{ic|.bashrc}} file:<br />
<br />
{{hc|~/.bashrc|<nowiki><br />
# Start the gpg-agent if not already running<br />
if ! pgrep -x -u "${USER}" gpg-agent >/dev/null 2>&1; then<br />
gpg-connect-agent /bye >/dev/null 2>&1<br />
fi<br />
</nowiki>}}<br />
<br />
Then set {{ic|SSH_AUTH_SOCK}} so that SSH will use ''gpg-agent'' instead of ''ssh-agent'':<br />
<br />
{{hc|~/.bashrc|<nowiki><br />
# Set SSH to use gpg-agent<br />
unset SSH_AGENT_PID<br />
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then<br />
export SSH_AUTH_SOCK="${HOME}/.gnupg/S.gpg-agent.ssh"<br />
fi<br />
</nowiki>}}<br />
<br />
Also set the GPG TTY and refresh the TTY in case user has switched into an X session. Example:<br />
<br />
{{Expansion|Not clear why this is necessary (even tha man page does not explain it).}}<br />
<br />
{{hc|~/.bashrc|<nowiki><br />
# Set GPG TTY<br />
export GPG_TTY=$(tty)<br />
<br />
# Refresh gpg-agent tty in case user switches into an X session<br />
gpg-connect-agent updatestartuptty /bye >/dev/null<br />
</nowiki>}}<br />
<br />
Once ''gpg-agent'' is running you can use ''ssh-add'' to approve keys, following the same steps as for [[SSH keys#ssh-agent|ssh-agent]]. The list of approved keys is stored in the {{ic|~/.gnupg/sshcontrol}} file. Once your key is approved, you will get a ''pinentry'' dialog every time your passphrase is needed. You can control passphrase caching in the {{ic|~/.gnupg/gpg-agent.conf}} file. The following example would have ''gpg-agent'' cache your keys for 3 hours:<br />
<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
default-cache-ttl-ssh 10800<br />
}}<br />
<br />
== Smartcards ==<br />
<br />
GnuPG uses ''scdaemon'' as an interface to your smartcard reader, please refer to the [[man page]] for details.<br />
<br />
=== GnuPG only setups ===<br />
<br />
{{Note| To allow scdaemon direct access to USB smarcard readers the optional dependency {{Pkg|libusb-compat}} have to be installed}}<br />
<br />
If you do not plan to use other cards but those based on GnuPG, you should check the {{Ic|reader-port}} parameter in {{ic|~/.gnupg/scdaemon.conf}}. The value '0' refers to the first available serial port reader and a value of '32768' (default) refers to the first USB reader.<br />
<br />
=== GnuPG with PSCD-Lite ===<br />
<br />
{{Note|{{Pkg|pcsclite}} and {{Pkg|ccid}} have to be installed, and the contained [[systemd#Using units|systemd]] service {{ic|pcscd.service}} has to be running, or the socket {{ic|pscd.socket}} has to be listening.}}<br />
<br />
PSCD-Lite is a daemon which handles access to smartcard (SCard API). If GnuPG's scdaemon fails to connect the smartcard directly (e.g. by using its integrated CCID support), it will fallback and try to find a smartcard using the PSCD-Lite driver.<br />
<br />
==== Always use PSCD-Light ====<br />
<br />
If you are using any smartcard with an opensc driver (e.g.: ID cards from some countries) you should pay some attention to GnuPG configuration. Out of the box you might receive a message like this when using {{Ic|gpg --card-status}}<br />
<br />
gpg: selecting openpgp failed: ec=6.108<br />
<br />
By default, scdaemon will try to connect directly to the device. This connection will fail if the reader is being used by another process. For example: the pcscd daemon used by OpenSC. To cope with this situation we should use the same underlying driver as opensc so they can work well together. In order to point scdaemon to use pcscd you should remove {{Ic|reader-port}} from {{ic|~/.gnupg/scdaemon.conf}}, specify the location to {{ic|libpcsclite.so}} library and disable ccid so we make sure that we use pcscd:<br />
<br />
{{hc|~/.gnupg/scdaemon.conf|<nowiki><br />
pcsc-driver /usr/lib/libpcsclite.so<br />
card-timeout 5<br />
disable-ccid<br />
</nowiki>}}<br />
<br />
Please check {{Ic|man scdaemon}} if you do not use OpenSC.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Different algorithm ===<br />
<br />
You may want to use stronger algorithms:<br />
<br />
{{hc|~/.gnupg/gpg.conf|<br />
...<br />
<br />
personal-digest-preferences SHA512<br />
cert-digest-algo SHA512<br />
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed<br />
personal-cipher-preferences TWOFISH CAMELLIA256 AES 3DES<br />
}}<br />
<br />
In the latest version of GnuPG, the default algorithms used are SHA256 and AES, both of which are secure enough for most people. However, if you are using a version of GnuPG older than 2.1, or if you want an even higher level of security, then you should follow the above step.<br />
<br />
=== Encrypt a password ===<br />
<br />
It can be useful to encrypt some password, so it will not be written in clear on a configuration file. A good example is your email password.<br />
<br />
First create a file with your password. You '''need''' to leave '''one''' empty line after the password, otherwise gpg will return an error message when evaluating the file.<br />
<br />
Then run:<br />
<br />
$ gpg -e -a -r ''<user-id>'' ''your_password_file''<br />
<br />
{{ic|-e}} is for encrypt, {{ic|-a}} for armor (ASCII output), {{ic|-r}} for recipient user ID.<br />
<br />
You will be left with a new {{ic|''your_password_file''.asc}} file.<br />
<br />
=== Revoking a key ===<br />
<br />
{{Warning|<br />
*Anybody having access to your revocation certificate can revoke your key, rendering it useless.<br />
*Key revocation should only be performed if your key is compromised or lost, or you forget your passphrase.}}<br />
<br />
Revocation certificates are automatically generated for newly generated keys, although one can be generated manually by the user later. These are located at {{ic|~/.gnupg/openpgp-revocs.d/}}. The filename of the certificate is the fingerprint of the key it will revoke.<br />
<br />
To revoke your key, simply import the revocation certificate:<br />
<br />
$ gpg --import ''<fingerprint>''.rev<br />
<br />
Now update the keyserver:<br />
<br />
$ gpg --keyserver subkeys.pgp.net --send ''<userid>''<br />
<br />
=== Change trust model ===<br />
<br />
By default GnuPG uses the [[Wikipedia::Web of Trust|Web of Trust]] as the trust model. You can change this to [[Wikipedia::Trust on First|Trust on First]] Use by adding {{ic|1=--trust-model=tofu}} when adding a key or adding this option to your GnuPG configuration file. More details are in [https://lists.gnupg.org/pipermail/gnupg-devel/2015-October/030341.html this email to the GnuPG list].<br />
<br />
=== Hide all recipient id's ===<br />
<br />
By default the recipient's key ID is in the encrypted message. This can be removed at encryption time for a recipient by using {{ic|hidden-recipient ''<user-id>''}}. To remove it for all recipients add {{ic|throw-keyids}} to your configuration file. This helps to hide the receivers of the message and is a limited countermeasure against traffic analysis. (Using a little social engineering anyone who is able to decrypt the message can check whether one of the other recipients is the one he suspects.) On the receiving side, it may slow down the decryption process because all available secret keys must be tried (''e.g.'' with {{ic|--try-secret-key ''<user-id>''}}).<br />
<br />
=== Using caff for keysigning parties ===<br />
<br />
To allow users to validate keys on the keyservers and in their keyrings (i.e. make sure they are from whom they claim to be), PGP/GPG uses he [[Wikipedia::Web of Trust|Web of Trust]]. Keysigning parties allow users to get together in physical location to validate keys. The [[Wikipedia:Zimmermann–Sassaman key-signing protocol|Zimmermann-Sassaman]] key-signing protocol is a way of making these very effective. [http://www.cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html Here] you will find a how-to article.<br />
<br />
For an easier process of signing keys and sending signatures to the owners after a keysigning party, you can use the tool ''caff''. It can be installed from the AUR with the package {{AUR|caff-svn}} or bundled together with other useful tools in the package {{AUR|signing-party-svn}}{{Broken package link|{{aur-mirror|signing-party-svn}}}}.<br />
Either way, there will be a lot of dependencies installing from the AUR. Alternatively you can install them from CPAN with<br />
cpanm Any::Moose<br />
cpanm GnuPG::Interface<br />
<br />
To send the signatures to their owners you need a working [[Wikipedia:Message transfer agent|MTA]]. If you do not have already one, install [[msmtp]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Not enough random bytes available ===<br />
When generating a key, gpg can run into this error:<br />
Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy!<br />
To check the available entropy, check the kernel parameters:<br />
cat /proc/sys/kernel/random/entropy_avail<br />
A healthy Linux system with a lot of entropy available will have return close to the full 4,096 bits of entropy. If the value returned is less than 200, the system is running low on entropy. <br />
<br />
To solve it, remember you do not often need to create keys and best just do what the message suggests (e.g. create disk activity, move the mouse, edit the wiki - all will create entropy). If that does not help, check which service is using up the entropy and consider stopping it for the time. If that is no alternative, see [[Random number generation#Faster alternatives]].<br />
<br />
=== su ===<br />
<br />
When using {{Ic|pinentry}}, you must have the proper permissions of the terminal device (e.g. {{Ic|/dev/tty1}}) in use. However, with ''su'' (or ''sudo''), the ownership stays with the original user, not the new one. This means that pinentry will fail, even as root. The fix is to change the permissions of the device at some point before the use of pinentry (i.e. using gpg with an agent). If doing gpg as root, simply change the ownership to root right before using gpg:<br />
<br />
chown root /dev/ttyN # where N is the current tty<br />
<br />
and then change it back after using gpg the first time. The equivalent is likely to be true with {{Ic|/dev/pts/}}.<br />
<br />
{{Note|The owner of tty ''must'' match with the user for which pinentry is running. Being part of the group {{Ic|tty}} '''is not''' enough.}}<br />
<br />
=== Agent complains end of file ===<br />
<br />
The default pinentry program is pinentry-gtk-2, which needs a DBus session bus to run properly. See [[General troubleshooting#Session permissions]] for details.<br />
<br />
Alternatively, you can use {{ic|pinentry-qt}}. See [[#pinentry]].<br />
<br />
=== KGpg configuration permissions ===<br />
<br />
There have been issues with {{Pkg|kdeutils-kgpg}} being able to access the {{ic|~/.gnupg/}} options. One issue might be a result of a deprecated ''options'' file, see the [https://bugs.kde.org/show_bug.cgi?id=290221 bug] report.<br />
<br />
Another user reported that ''KGpg'' failed to start until the {{ic|~/.gnupg}} folder is set to {{ic|drwxr-xr-x}} permissions. If you require this work-around, ensure that the directory contents retain {{ic|-rw-------}} permissions! Further, report it as a bug to the [https://bugs.kde.org/buglist.cgi?quicksearch=kgpg developers].<br />
<br />
=== Conflicts between gnome-keyring and gpg-agent ===<br />
<br />
{{Accuracy|See [[#GPG_AGENT_INFO]]}}<br />
<br />
While the Gnome keyring implements a GPG agent component, as of GnuPG version 2.1, GnuPG ignores the {{ic|GPG_AGENT_INFO}} environment variable, so that Gnome keyring can no longer be used as a GPG agent.<br />
<br />
However, since version 0.9.6 the package {{Pkg|pinentry}} provides the {{Ic|pinentry-gnome3}} program. You may set the following option in your {{Ic|gpg-agent.conf}} file<br />
pinentry-program /usr/bin/pinentry-gnome3<br />
in order to make use of that pinentry program.<br />
<br />
Since version 0.9.2 all pinentry programs can be configured to optionally save a passphrase with libsecret. For example, when the user is asked for a passphrase via {{Ic|pinentry-gnome3}}, a checkbox is shown whether to save the passphrase using a password manager. Unfortunately, the package {{Pkg|pinentry}} does not have this feature enabled (see {{Bug|46059}} for the reasons). You may use {{AUR|pinentry-libsecret}} as a replacement for it, which has support for libsecret enabled.<br />
<br />
=== mutt and gpg ===<br />
<br />
To be asked for your GnuPG password only once per session as of GnuPG 2.1, see [https://bbs.archlinux.org/viewtopic.php?pid=1490821#p1490821 this forum thread].<br />
<br />
=== "Lost" keys, upgrading to gnupg version 2.1 ===<br />
<br />
When {{ic|gpg --list-keys}} fails to show keys that used to be there, and applications complain about missing or invalid keys, some keys may not have been migrated to the new format.<br />
<br />
Please read [http://jo-ke.name/wp/?p=111 GnuPG invalid packet workaround]. Basically, it says that there is a bug with keys in the old {{ic|pubring.gpg}} and {{ic|secring.gpg}} files, which have now been superseded by the new {{ic|pubring.kbx}} file and the {{ic|private-keys-v1.d/}} subdirectory and files. Your missing keys can be recovered with the following commnads:<br />
<br />
$ cd<br />
$ cp -r .gnupg gnupgOLD<br />
$ gpg --export-ownertrust > otrust.txt<br />
$ gpg --import .gnupg/pubring.gpg<br />
$ gpg --import-ownertrust otrust.txt<br />
$ gpg --list-keys<br />
<br />
=== gpg hanged for all keyservers (when trying to receive keys) ===<br />
<br />
If gpg hanged with a certain keyserver when trying to receive keys, you might need to kill dirmngr in order to get access to other keyservers which are actually working, otherwise it might keeping hanging for all of them.<br />
<br />
=== Smartcard not detected ===<br />
<br />
Your user might not have the permission to access the smartcard which results in a {{ic|card error}} to be thrown, even though the card is correctly set up and inserted.<br />
<br />
One possible solution is to add a new group {{ic|scard}} including the users who need access to the smartcard.<br />
<br />
Then use an [[Udev#Writing_udev_rules|udev]] rule, similar to the following:<br />
{{hc|/etc/udev/rules.d/71-gnupg-ccid.rules|<nowiki><br />
ACTION=="add", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="1050", ENV{ID_MODEL_ID}=="0116|0111", MODE="660", GROUP="scard"<br />
</nowiki>}}<br />
One needs to adapt VENDOR and MODEL according to the {{ic|lsusb}} output, the above example is for a YubikeyNEO.<br />
<br />
== See also ==<br />
<br />
* [https://gnupg.org/ GNU Privacy Guard Homepage]<br />
* [https://fedoraproject.org/wiki/Creating_GPG_Keys Creating GPG Keys (Fedora)]<br />
* [https://wiki.debian.org/Subkeys OpenPGP subkeys in Debian]<br />
* [http://blog.sanctum.geek.nz/series/linux-crypto/ A more comprehensive gpg Tutorial]<br />
* [https://help.riseup.net/en/security/message-security/openpgp/gpg-best-practices gpg.conf recommendations and best practices]<br />
* [https://github.com/ioerror/torbirdy/blob/master/gpg.conf Torbirdy gpg.conf]<br />
* [https://www.reddit.com/r/GPGpractice/ /r/GPGpractice - a subreddit to practice using GnuPG.]</div>Ritkahttps://wiki.archlinux.org/index.php?title=Talk:GnuPG&diff=434215Talk:GnuPG2016-05-07T12:04:04Z<p>Ritka: /* inaccuracies in #Encrypt_and_decrypt section */</p>
<hr />
<div>== <s>Error with warning under ''Backup your private key'' </s>==<br />
<br />
I took notice of the warning under the header ''Backup your private key'' and I am pretty certain it is an error. <br />
<br />
Exported secret keys are encrypted using your paraphrase. See the attached link.<br />
<br />
http://lists.gnupg.org/pipermail/gnupg-users/2012-June/044606.html<br />
<br />
Ever notice how you don't need to enter your paraphrase to export a secret key? It's because you're not decrypting it. The secret key you're exporting is still encrypted! Try exporting a key, then import it on another machine (if possible)... Notice that you still need your passphrase on the new machine to actually use the key because the secret key you imported was encrypted. You can't do anything with an encrypted private key. GnuPG will NEVER export a unencrypted private key unless you explicitly ask it to using ''--export-reset-subkey-password'' or similar option.<br />
<br />
http://stackoverflow.com/questions/9981099/are-exported-private-keys-in-gpg-still-encrypted<br />
<br />
I did see some conflicting information however saying that exported private keys aren't protected. However, they are. I know they are. Look at the source code. Inspect the exported key's packets. It's encrypted. GnuPG isn't that stupid.<br />
<br />
I think this warning is an error, and is causing many people to be hesitant to backup their keys.<br />
<br />
GnuPG exported secret keys are always encrypted on export. If it wasn't the case, you'd need your passphrase before export to get the raw unencrypted key. In order to preform crypto operations on someone's behalf (especially signing), like the warning states, you'd need their passphrase to the exported secret key.<br />
<br />
Before I go ahead and change this page, I just wanted to get some input and see if I'm wrong.<br />
<br />
[[User:JCBird1012|JCBird1012]] ([[User talk:JCBird1012|talk]]) 13:03, 27 April 2016 (UTC) <br />
<br />
:Hi, thanks for pointing it out. You are right, I think it was a simple hickup referencing old gnugpg releases. The references you use above are not ideal for the same reason, by the way. In particular the first link contains some fallacies in its second paragraph. Also note gnugpg will indeed regain functionality to export the secret-key ''without'' the passphrase sometime: [https://bugs.gnupg.org/gnupg/issue2070], [https://bugs.gnupg.org/gnupg/issue2324]. .. Please don't call them stupid for it now ;) .. as so often security is torn by everyday use cases, it's simple as that. <br />
:I have changed the warning with [https://wiki.archlinux.org/index.php?title=GnuPG&type=revision&diff=433009&oldid=433008 this edit]. How do you like it? You are welcome to edit it freely to improve on it (applies to anything in this wiki, just make sure to [[ArchWiki:Contributing#Always properly use the edit summary]], so that others understand the what and why). <br />
:--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:29, 28 April 2016 (UTC)<br />
<br />
::Thanks for editing that. It's great! Hopefully many users now feel comfortable exporting and backing up their private key to a secure medium (just in case disaster strikes).<br />
<br />
::Just a quick note. The first bug, while an issue, is mainly irrelevant to the majority to GnuPG users, since it only affects the 2.1 release, which is the modern version. In many distributions, this version is not installed, or if it is, is not the primary version used. The second issue only applies if the key doesn't have a passphrase. This again only affects a small set of GnuPG users as many users choose to use a passphrase with their key (assuming they're aware of good key security practices). GnuPG will prompt the user, confirming that a passphrase isn't desired. But thank you for pointing those issues out, nonetheless (I didn't know they existed before now.) <br />
::While bugs do exist, I'm sure an issue as big as exporting private keys in plaintext would be taken extremely seriously and patched quickly by the GnuPG developers. <br />
<br />
::Though you shouldn't fully trust any software, many people rely on GnuPG every single day to protect what matters to them. It's an imortant piece of software to many people, and as a community, we should take every step to ensure the accuracy of the information we're sharing. I might have come off slightly strong in my first post, but I can get that way with serious matters ;). <br />
<br />
::Thanks for all your help Indigo!<br />
<br />
:::[[User:JCBird1012|JCBird1012]] ([[User talk:JCBird1012|talk]]) 20:21, 6 May 2016 (UTC)<br />
<br />
:::Ok, great, thanks for feedback. Closing this item then. Quick reply regarding releases: We don't usually reference release information, it only complicates reading flow. One of the benefits Arch users cherish is having latest stable software releases rolled out to them very fast. It is only natural ArchWiki can be expected and strives to contain up-to-date info everywhere (& thanks to our many contributors who care that works pretty well). For this edit it seemed useful to reference release info, to notify about a new feature with different application behaviour, but it is one of few exceptions really. If you (/anyone) see something else which is outdated but can't fix it right away, putting a status template like [[Template:Out of date]] or [[Template:Accuracy]] also helps. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:50, 7 May 2016 (UTC)<br />
<br />
== inaccuracies in #Encrypt_and_decrypt section ==<br />
<br />
Hey, I am not quite sure about the correctness about some statements in the mentioned sections. At least they are inaccurate about the basic principles of public-key cryptography, wich is in my opinion the main usage of pgp.<br />
<br />
The points I am not sure about and where I would like to hear someone elses opinion are:<br />
1) "When encrypting or decrypting it is possible to have more than one private key in use."<br />
I think that is not about private but about public keys. You can of course have multiple private keys in you keyring, but I don't know how you can need more than one to decrypt a file.<br />
<br />
2) According to 1) the rest of the pragraph doesn't make much sense to me, too. It's true that the '-u' option lets you chose the private key to use. But usually an encrypted file contains informations about the keys it is encrypted with, so you won't need that in most of the cases.<br />
<br />
3) "$ gpg --encrypt --armor doc" This command seems also a bit odd to me, because it doesn't specify a recipient. When I enter it gpg complains to me about that and asks me interactively to specify a recipient. I mean there is nothing wrong about it, but it does not convey the concept of public-key cryptography. At least it should be stated, that gpg will ask you for the recipients.<br />
<br />
Maybe that wiki page shall not be a tutorial on public-key cryptography, but if you are new to that, you are very likely to be confused by these inaccuracies, I think.<br />
<br />
If there were any intentions behind that section which I have missed, I would appreciate to hear them. Otherwise I would try to rewrite it.<br />
--[[User:Ritka|Ritka]] ([[User talk:Ritka|talk]]) 12:04, 7 May 2016 (UTC)</div>Ritkahttps://wiki.archlinux.org/index.php?title=Talk:GnuPG&diff=434214Talk:GnuPG2016-05-07T12:00:51Z<p>Ritka: /* inaccuracies in #Encrypt_and_decrypt section */ new section</p>
<hr />
<div>== <s>Error with warning under ''Backup your private key'' </s>==<br />
<br />
I took notice of the warning under the header ''Backup your private key'' and I am pretty certain it is an error. <br />
<br />
Exported secret keys are encrypted using your paraphrase. See the attached link.<br />
<br />
http://lists.gnupg.org/pipermail/gnupg-users/2012-June/044606.html<br />
<br />
Ever notice how you don't need to enter your paraphrase to export a secret key? It's because you're not decrypting it. The secret key you're exporting is still encrypted! Try exporting a key, then import it on another machine (if possible)... Notice that you still need your passphrase on the new machine to actually use the key because the secret key you imported was encrypted. You can't do anything with an encrypted private key. GnuPG will NEVER export a unencrypted private key unless you explicitly ask it to using ''--export-reset-subkey-password'' or similar option.<br />
<br />
http://stackoverflow.com/questions/9981099/are-exported-private-keys-in-gpg-still-encrypted<br />
<br />
I did see some conflicting information however saying that exported private keys aren't protected. However, they are. I know they are. Look at the source code. Inspect the exported key's packets. It's encrypted. GnuPG isn't that stupid.<br />
<br />
I think this warning is an error, and is causing many people to be hesitant to backup their keys.<br />
<br />
GnuPG exported secret keys are always encrypted on export. If it wasn't the case, you'd need your passphrase before export to get the raw unencrypted key. In order to preform crypto operations on someone's behalf (especially signing), like the warning states, you'd need their passphrase to the exported secret key.<br />
<br />
Before I go ahead and change this page, I just wanted to get some input and see if I'm wrong.<br />
<br />
[[User:JCBird1012|JCBird1012]] ([[User talk:JCBird1012|talk]]) 13:03, 27 April 2016 (UTC) <br />
<br />
:Hi, thanks for pointing it out. You are right, I think it was a simple hickup referencing old gnugpg releases. The references you use above are not ideal for the same reason, by the way. In particular the first link contains some fallacies in its second paragraph. Also note gnugpg will indeed regain functionality to export the secret-key ''without'' the passphrase sometime: [https://bugs.gnupg.org/gnupg/issue2070], [https://bugs.gnupg.org/gnupg/issue2324]. .. Please don't call them stupid for it now ;) .. as so often security is torn by everyday use cases, it's simple as that. <br />
:I have changed the warning with [https://wiki.archlinux.org/index.php?title=GnuPG&type=revision&diff=433009&oldid=433008 this edit]. How do you like it? You are welcome to edit it freely to improve on it (applies to anything in this wiki, just make sure to [[ArchWiki:Contributing#Always properly use the edit summary]], so that others understand the what and why). <br />
:--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:29, 28 April 2016 (UTC)<br />
<br />
::Thanks for editing that. It's great! Hopefully many users now feel comfortable exporting and backing up their private key to a secure medium (just in case disaster strikes).<br />
<br />
::Just a quick note. The first bug, while an issue, is mainly irrelevant to the majority to GnuPG users, since it only affects the 2.1 release, which is the modern version. In many distributions, this version is not installed, or if it is, is not the primary version used. The second issue only applies if the key doesn't have a passphrase. This again only affects a small set of GnuPG users as many users choose to use a passphrase with their key (assuming they're aware of good key security practices). GnuPG will prompt the user, confirming that a passphrase isn't desired. But thank you for pointing those issues out, nonetheless (I didn't know they existed before now.) <br />
::While bugs do exist, I'm sure an issue as big as exporting private keys in plaintext would be taken extremely seriously and patched quickly by the GnuPG developers. <br />
<br />
::Though you shouldn't fully trust any software, many people rely on GnuPG every single day to protect what matters to them. It's an imortant piece of software to many people, and as a community, we should take every step to ensure the accuracy of the information we're sharing. I might have come off slightly strong in my first post, but I can get that way with serious matters ;). <br />
<br />
::Thanks for all your help Indigo!<br />
<br />
:::[[User:JCBird1012|JCBird1012]] ([[User talk:JCBird1012|talk]]) 20:21, 6 May 2016 (UTC)<br />
<br />
:::Ok, great, thanks for feedback. Closing this item then. Quick reply regarding releases: We don't usually reference release information, it only complicates reading flow. One of the benefits Arch users cherish is having latest stable software releases rolled out to them very fast. It is only natural ArchWiki can be expected and strives to contain up-to-date info everywhere (& thanks to our many contributors who care that works pretty well). For this edit it seemed useful to reference release info, to notify about a new feature with different application behaviour, but it is one of few exceptions really. If you (/anyone) see something else which is outdated but can't fix it right away, putting a status template like [[Template:Out of date]] or [[Template:Accuracy]] also helps. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:50, 7 May 2016 (UTC)<br />
<br />
== inaccuracies in #Encrypt_and_decrypt section ==<br />
<br />
Hey, I am not quite sure about the correctness about some statements in the mentioned sections. At least they are inaccurate about the basic principles of public-key cryptography, wich is in my opinion the main usage of pgp.<br />
<br />
The points I am not sure about and where I would like to hear someone elses opinion are:<br />
1) "When encrypting or decrypting it is possible to have more than one private key in use."<br />
I think that is not about private but about public keys. You can of course have multiple private keys in you keyring, but I don't know how you can need more than one to decrypt a file.<br />
<br />
2) According to 1) the rest of the pragraph doesn't make much sense to me, too. It's true that the '-u' option lets you chose the private key to use. But usually an encrypted file contains informations about the keys it is encrypted with, so you won't need that in most of the cases.<br />
<br />
3) "$ gpg --encrypt --armor doc" This command seems also a bit odd to me, because it doesn't specify a recipient. When I enter it gpg complains to me about that and asks me interactively to specify a recipient. I mean there is nothing wrong about it, but it does not convey the concept of public-key cryptography. At least it should be stated, that gpg will ask you for the recipients.<br />
<br />
Maybe that wiki page shall not be a tutorial on public-key cryptography, but if you are new to that, you are very likely to be confused by these inaccuracies, I think.<br />
<br />
If there were any intentions behind that section which I have missed, I would appreciate to hear them. Otherwise I would try to rewrite it.</div>Ritkahttps://wiki.archlinux.org/index.php?title=GnuPG&diff=433750GnuPG2016-05-03T16:19:16Z<p>Ritka: corrected the last paragraph in "Encrypt and Decrypt". You do not need the senders public key to decrypt messages from him, but the sender needs your public key to encryt messages for you!</p>
<hr />
<div>[[Category:Encryption]]<br />
[[es:GnuPG]]<br />
[[ja:GnuPG]]<br />
[[ru:GnuPG]]<br />
[[zh-cn:GnuPG]]<br />
{{Related articles start}}<br />
{{Related|pacman/Package signing}}<br />
{{Related|Disk encryption}}<br />
{{Related|List of applications/Security#Encryption, signing, steganography}}<br />
{{Related articles end}}<br />
<br />
According to the [http://www.gnupg.org official website]:<br />
<br />
:GnuPG is a complete and free implementation of the OpenPGP standard as defined by RFC4880 (also known as [[Wikipedia:PGP|PGP]]). GnuPG allows to encrypt and sign your data and communication, features a versatile key management system as well as access modules for all kinds of public key directories. GnuPG, also known as GPG, is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries are available. Version 2 of GnuPG also provides support for S/MIME and Secure Shell (ssh).<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|gnupg}} package.<br />
<br />
This will also install {{Pkg|pinentry}}, a collection of simple PIN or passphrase entry dialogs which GnuPG uses for passphrase entry. Which ''pinentry'' dialog is used is determined by the symbolic link {{ic|/usr/bin/pinentry}}, which by default points to {{ic|/usr/bin/pinentry-gtk-2}}.<br />
<br />
If you want to use a graphical frontend or program that integrates with GnuPG, see [[List of applications/Security#Encryption, signing, steganography]].<br />
<br />
== Configuration ==<br />
<br />
=== Directory location ===<br />
{{ic|$GNUPGHOME}} is used by GnuPG to point to the directory where its configuration files are stored. By default {{ic|$GNUPGHOME}} is not set and your {{ic|$HOME}} is used instead; thus, you will find a {{ic|~/.gnupg}} directory right after installation. <br />
<br />
To change the default location, either run gpg this way {{ic|$ gpg --homedir ''path/to/file''}} or set {{ic|GNUPGHOME}} in one of your regular [[startup files]].<br />
<br />
=== Configuration files ===<br />
<br />
The default configuration files are {{ic|~/.gnupg/gpg.conf}} and {{ic|~/.gnupg/dirmngr.conf}}. <br />
<br />
By default, the gnupg directory has its [[permissions]] set to {{ic|700}} and the files it contains have their permissions set to {{ic|600}}. Only the owner of the directory has permission to read, write, and access the files. This is for security purposes and should not be changed. In case this directory or any file inside it does not follow this security measure, you will get warnings about unsafe file and home directory permissions.<br />
<br />
Append to these files any long options you want. Do not write the two dashes, but simply the name of the option and required arguments. You will find skeleton files in {{ic|/usr/share/gnupg}}. These files are copied to {{ic|~/.gnupg}} the first time gpg is run if they do not exist there. Other examples are found in [[#See also]].<br />
<br />
Additionally, [[pacman]] uses a different set of configuration files for package signature verification. See [[Pacman/Package signing]] for details.<br />
<br />
=== Default options for new users ===<br />
<br />
If you want to setup some default options for new users, put configuration files in {{ic|/etc/skel/.gnupg/}}. When the new user is added in system, files from here will be copied to its GnuPG home directory. There is also a simple script called ''addgnupghome'' which you can use to create new GnuPG home directories for existing users:<br />
<br />
# addgnupghome user1 user2<br />
<br />
This will add the respective {{ic|/home/user1/.gnupg}} and {{ic|/home/user2/.gnupg}} and copy the files from the skeleton directory to it. Users with existing GnuPG home directory are simply skipped.<br />
<br />
== Usage ==<br />
<br />
{{Note|Whenever a ''{{ic|<user-id>}}'' is required in a command, it can be specified with your key ID, fingerprint, a part of your name or email address, etc. GnuPG is flexible on this.<br />
}}<br />
<br />
=== Create key pair ===<br />
<br />
Generate a key pair by typing in a terminal:<br />
<br />
$ gpg --full-gen-key<br />
<br />
{{Tip|Use the {{ic|--expert}} option for getting alternative ciphers like [[wikipedia:Elliptic_curve_cryptography|ECC]].}}<br />
<br />
The command will prompt for answers to several questions. For general use most people will want: <br />
<br />
* the RSA (sign only) and a RSA (encrypt only) key.<br />
* a keysize of the default value (2048). A larger keysize of 4096 "gives us almost nothing, while costing us quite a lot"[https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096].<br />
* an expiration date. A period of a year is good enough for the average user. This way even if access is lost to the keyring, it will allow others to know that it is no longer valid. Later, if necessary, the expiration date can be extended without having to re-issue a new key.<br />
* your name and email address. You can add multiple identities to the same key later (''e.g.'', if you have multiple email addresses you want to associate with this key).<br />
* ''no'' optional comment. Since the semantics of the comment field are [https://lists.gnupg.org/pipermail/gnupg-devel/2015-July/030150.html not well-defined], it has limited value for identification.<br />
* [[Security#Choosing_secure_passwords|a secure passphrase]].<br />
<br />
{{Note|The name and email address you enter here will be seen by anybody who imports your key.}}<br />
<br />
=== List keys ===<br />
<br />
To list keys in your public key ring:<br />
<br />
$ gpg --list-keys<br />
<br />
To list keys in your secret key ring:<br />
<br />
$ gpg --list-secret-keys<br />
<br />
=== Export your public key ===<br />
<br />
In order for others to send encrypted messages to you, they need your public key.<br />
<br />
To generate an ASCII version of your public key (''e.g.'' to distribute it by e-mail):<br />
<br />
$ gpg --armor --output ''public.key'' --export ''<user-id>''<br />
<br />
Alternatively, or in addition, you can [[#Use a keyserver]] to share your key. <br />
<br />
{{Tip|Add {{ic|--no-emit-version}} to avoid printing the version number, or add the corresponding setting to your configuration file.}}<br />
<br />
=== Import a key ===<br />
<br />
In order to encrypt messages to others, as well as verify their signatures, you need their public key. To import a public key with file name {{ic|''public.key''}} to your public key ring:<br />
<br />
$ gpg --import ''public.key''<br />
<br />
Alternatively, [[#Use a keyserver]] to find a public key.<br />
<br />
=== Use a keyserver ===<br />
<br />
You can register your key with a public PGP key server, so that others can retrieve your key without having to contact you directly:<br />
<br />
$ gpg --send-keys ''<key-id>''<br />
<br />
To find out details of a key on the keyserver, without importing it, do:<br />
<br />
$ gpg --search-keys ''<key-id>''<br />
<br />
To import a key from a key server:<br />
<br />
$ gpg --recv-keys ''<key-id>''<br />
<br />
{{Warning|Anyone can send keys to a keyserver, so you should not trust that the key you download actually belongs to the individual listed. You should verify the authenticity of the retrieved public key by comparing its fingerprint with one that the owner published on an independent source, such as their own blog or website, or contacting them by email, over the phone or in person. Using multiple authentication sources will increase the level of trust you can give to the downloaded key. See [[Wikipedia:Public key fingerprint]] for more information.}}<br />
<br />
{{Tip|<br />
* Adding {{ic|keyserver-options auto-key-retrieve}} to {{ic|gnupg.conf}} will automatically fetch keys from the key server as needed.<br />
* An alternative key server is {{ic|pool.sks-keyservers.net}} and can be specified with {{ic|keyserver}} in {{ic|dirmngr.conf}}.; see also [[wikipedia:Key server (cryptographic)#Keyserver examples]].<br />
* You can connect to the keyserver over [[Tor]] using {{ic|--use-tor}}. {{ic|hkp://jijrk5u4osbsr34t5.onion}} is the onion address for the sks-keyservers pool. [https://gnupg.org/blog/20151224-gnupg-in-november-and-december.html See this GnuPG blog post] for more information.<br />
* You can connect to a keyserver using a proxy by setting the {{ic|http_proxy}} environment variable and setting {{ic|honor-http-proxy}} in {{ic|dirmngr.conf}}. Alternatively, set {{ic|http-proxy ''host[:port]''}} in {{ic|dirmngr.conf}}, overriding the {{ic|http_proxy}} environment variable.}}<br />
<br />
=== Encrypt and decrypt ===<br />
<br />
When encrypting or decrypting it is possible to have more than one private key in use. If this occurs you need to select the active key by using the option {{ic|-u ''<user-id>''}} or {{ic|--local-user ''<user-id>''}}.<br />
<br />
To encrypt a file named {{ic|''doc''}} using ASCII armor (suitable for copying and pasting a message in text format), use:<br />
<br />
$ gpg --encrypt --armor ''doc''<br />
<br />
If you want to just encrypt a file, exclude {{ic|--armor}}.<br />
<br />
{{Tip|<br />
* If you want to change recipient this can be done by the option {{ic|-r ''<user-id>''}} (or {{ic|--recipient ''<user-id>''}}).<br />
* Add {{ic|-R ''<user-id>''}} or {{ic|--hidden-recipient ''<user-id>''}} instead of {{ic|--recipient}} to not put the recipient key IDs in the encrypted message. This helps to hide the receivers of the message and is a limited countermeasure against traffic analysis.<br />
* Add {{ic|--no-emit-version}} to avoid printing the version number, or add the corresponding setting to your configuration file.}}<br />
<br />
{{Note|You can use gnupg to encrypt your sensitive documents, but only individual files at a time. If you want to encrypt directories or a whole file-system you should consider using [[TrueCrypt]] or [[EncFS]], though you can always tarball various files and then encrypt them.}}<br />
<br />
To decrypt a file encrypted with your public key, use:<br />
<br />
$ gpg --decrypt ''doc.asc''<br />
<br />
You will be prompted to enter your passphrase.<br />
<br />
== Key maintenance ==<br />
<br />
=== Backup your private key ===<br />
<br />
To backup your private key do the following:<br />
<br />
$ gpg --export-secret-keys --armor ''<user-id>'' > ''privkey.asc''<br />
<br />
Note that ''gpg'' release 2.1 changed default behaviour so that the above command enforces a passphrase protection, even if you deliberately chose not to use one on key creation. This is because otherwise anyone who gains access to the above exported file would be able to encrypt and sign documents as if they were you ''without'' needing to know your passphrase. <br />
<br />
{{Warning|The passphrase is usually the weakest link in protecting your secret key. Place the private key in a safe place on a different system/device, such as a locked container or encrypted drive. It is the only safety you have to regain control to your keyring in case of, for example, a drive failure, theft or worse.}}<br />
<br />
=== Edit your key ===<br />
<br />
Running the {{ic|gpg --edit-key ''<user-id>''}} command will present a menu which enables you to do most of your key management related tasks.<br />
<br />
Some useful commands in the edit key sub menu:<br />
> passwd # change the passphrase<br />
> clean # compact any user ID that is no longer usable (e.g revoked or expired)<br />
> revkey # revoke a key<br />
> addkey # add a subkey to this key<br />
> expire # change the key expiration time<br />
<br />
Type {{ic|help}} in the edit key sub menu for more commands.<br />
<br />
{{Tip|If you have multiple email accounts you can add each one of them as an identity, using {{ic|adduid}} command. You can then set your favourite one as {{ic|primary}}.}}<br />
<br />
=== Exporting subkey ===<br />
<br />
If you plan to use the same key across multiple devices, you may want to strip out your master key and only keep the bare minimum encryption subkey on less secure systems.<br />
<br />
First, find out which subkey you want to export.<br />
<br />
$ gpg -K<br />
<br />
Select only that subkey to export.<br />
<br />
$ gpg -a --export-secret-subkeys [subkey id]! > /tmp/subkey.gpg<br />
<br />
{{Warning|If you forget to add the !, all of your subkeys will be exported.}}<br />
<br />
At this point you could stop, but it is most likely a good idea to change the passphrase as well. Import the key into a temporary folder. <br />
<br />
$ gpg --homedir /tmp/gpg --import /tmp/subkey.gpg<br />
$ gpg --homedir /tmp/gpg --edit-key ''<user-id>''<br />
> passwd<br />
> save<br />
$ gpg --homedir /tmp/gpg -a --export-secret-subkeys [subkey id]! > /tmp/subkey.altpass.gpg<br />
<br />
{{Note|You will get a warning that the master key was not available and the password was not changed, but that can safely be ignored as the subkey password was.}}<br />
<br />
At this point, you can now use {{ic|/tmp/subkey.altpass.gpg}} on your other devices.<br />
<br />
=== Rotating subkeys ===<br />
<br />
{{Warning|'''Never''' delete your expired or revoked subkeys unless you have a good reason. Doing so will cause you to lose the ability to decrypt files encrypted with the old subkey. Please '''only''' delete expired or revoked keys from other users to clean your keyring.}}<br />
<br />
If you have set your subkeys to expire after a set time, you can create new ones. Do this a few weeks in advance to allow others to update their keyring.<br />
<br />
{{Note|You do not need to create a new key simply because it is expired. You can extend the expiration date.}}<br />
<br />
Create new subkey (repeat for both signing and encrypting key)<br />
<br />
$ gpg --edit-key ''<user-id>''<br />
> addkey<br />
<br />
And answer the following questions it asks (see previous section for suggested settings).<br />
<br />
Save changes<br />
<br />
> save<br />
<br />
Update it to a keyserver.<br />
<br />
$ gpg --keyserver pgp.mit.edu --send-keys ''<user-id>''<br />
<br />
{{Note|Revoking expired subkeys is unnecessary and arguably bad form. If you are constantly revoking keys, it may cause others to lack confidence in you.}}<br />
<br />
== Signatures ==<br />
<br />
Signatures certify and timestamp documents. If the document is modified, verification of the signature will fail. Unlike encryption which uses public keys to encrypt a document, signatures are created with the user's private key. The recipient of a signed document then verifies the signature using the sender's public key.<br />
<br />
=== Sign a file ===<br />
<br />
To sign a file use the {{ic|--sign}} or {{ic|-s}} flag:<br />
<br />
$ gpg --output ''doc.sig'' --sign ''doc''<br />
<br />
The above also encrypts the file and stores it in binary format.<br />
<br />
=== Clearsign a file or message ===<br />
<br />
To sign a file without compressing it into binary format use:<br />
<br />
$ gpg --clearsign ''doc''<br />
<br />
This wraps the document into an ASCII-armored signature, but does not modify the document.<br />
<br />
=== Make a detached signature ===<br />
<br />
To create a separate signature file to be distributed separately from the document or file itself, use the {{ic|--detach-sig}} flag:<br />
<br />
$ gpg --output ''doc.sig'' --detach-sig ''doc''<br />
<br />
This method is often used in distributing software projects to allow users to verify that the program has not been modified by a third part.<br />
<br />
=== Verify a signature ===<br />
<br />
To verify a signature use the {{ic|--verify}} flag:<br />
<br />
$ gpg --verify ''doc.sig''<br />
<br />
where {{ic|''doc.sig''}} is the signature you wish to verify.<br />
<br />
To verify and decrypt a file at the same time, use the {{ic|--decrypt}} flag as you normally would in decrypting a file.<br />
<br />
If you are verifying a detached signature, both the file and the signature must be present when verifying. For example, to verify Arch Linux's latest iso you would do:<br />
<br />
$ gpg --verify ''archlinux-<version>-dual.iso.sig''<br />
<br />
where {{ic|''archlinux-<version>-dual.iso''}} must be located in the same directory.<br />
<br />
== gpg-agent ==<br />
<br />
''gpg-agent'' is mostly used as daemon to request and cache the password for the keychain. This is useful if GnuPG is used from an external program like a mail client.<br />
<br />
Starting with GnuPG 2.1.0 the use of ''gpg-agent'' is required. ''gpg-agent'' is started on-demand by the GnuPG tools, so there is usually no reason to start it manually.<br />
<br />
=== Configuration ===<br />
<br />
gpg-agent can be configured via {{ic|~/.gnupg/gpg-agent.conf}} file. The configuration options are listed in {{ic|man gpg-agent}}. For example you can change cache ttl for unused keys:<br />
<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
default-cache-ttl 3600<br />
}}<br />
<br />
{{Tip|To cache your passphrase for the whole session, please run the following command:<br />
$ /usr/lib/gnupg/gpg-preset-passphrase --preset XXXXXX<br />
<br />
where XXXX is the keygrip. You can get its value when running {{ic|gpg --with-keygrip -K}}. Passphrase will be stored until {{ic|gpg-agent}} is restarted. If you set up {{ic|default-cache-ttl}} value, it will take precedence.<br />
}}<br />
<br />
=== Reload the agent ===<br />
<br />
After changing the configuration, reload the agent using ''gpg-connect-agent'':<br />
<br />
$ gpg-connect-agent reloadagent /bye<br />
<br />
The command should print {{ic|OK}}.<br />
<br />
=== pinentry ===<br />
<br />
Finally, the agent needs to know how to ask the user for the password. This can be set in the gpg-agent configuration file.<br />
<br />
The default uses a gtk dialog. There are other options - see {{ic|info pinentry}}. To change the dialog implementation set {{ic|pinentry-program}} configuration option:<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
<br />
# PIN entry program<br />
# pinentry-program /usr/bin/pinentry-curses<br />
# pinentry-program /usr/bin/pinentry-qt<br />
# pinentry-program /usr/bin/pinentry-kwallet<br />
<br />
pinentry-program /usr/bin/pinentry-gtk-2<br />
}}<br />
<br />
{{Tip|For using {{ic|/usr/bin/pinentry-kwallet}} you have to install the {{Pkg|kwalletcli}} package.}}<br />
<br />
After making this change, reload the gpg-agent.<br />
<br />
=== Start gpg-agent with systemd user ===<br />
<br />
It is possible to use the [[Systemd/User]] facilities to start the agent.<br />
<br />
Create a systemd unit file:<br />
<br />
{{hc|~/.config/systemd/user/gpg-agent.service|2=<br />
[Unit]<br />
Description=GnuPG private key agent<br />
IgnoreOnIsolate=true<br />
<br />
[Service]<br />
Type=forking<br />
ExecStart=/usr/bin/gpg-agent --daemon<br />
Restart=on-abort<br />
<br />
[Install]<br />
WantedBy=default.target<br />
}}<br />
<br />
{{Note|If you use non-default value for the [[#GNUPGHOME]] environment variable, you need to pass it to the service. See [[systemd/User#Environment variables]] for details.}}<br />
<br />
=== Unattended passphrase ===<br />
<br />
Starting with GnuPG 2.1.0 the use of gpg-agent and pinentry is required, which may break backwards compatibility for passphrases piped in from STDIN using the {{ic|--passphrase-fd 0}} commandline option. In order to have the same type of functionality as the older releases two things must be done:<br />
<br />
First, edit the gpg-agent configuration to allow ''loopback'' pinentry mode:<br />
<br />
{{hc|1=~/.gnupg/gpg-agent.conf|2=<br />
allow-loopback-pinentry<br />
}}<br />
<br />
Restart the gpg-agent process if it is running to let the change take effect.<br />
<br />
Second, either the application needs to be updated to include a commandline parameter to use loopback mode like so:<br />
<br />
$ gpg --pinentry-mode loopback ...<br />
<br />
...or if this is not possible, add the option to the configuration:<br />
<br />
{{hc|1=~/.gnupg/gpg.conf|2=<br />
pinentry-mode loopback<br />
}}<br />
<br />
{{Note|The upstream author indicates setting {{ic|pinentry-mode loopback}} in {{ic|gpg.conf}} may break other usage, using the commandline option should be preferred if at all possible. [https://bugs.g10code.com/gnupg/issue1772]}}<br />
<br />
=== SSH agent ===<br />
<br />
''gpg-agent'' has OpenSSH agent emulation. If you already use the GnuPG suite, you might consider using its agent to also cache your SSH keys. Additionally, some users may prefer the PIN entry dialog GnuPG agent provides as part of its passphrase management.<br />
<br />
To start using GnuPG agent for your SSH keys, enable SSH support in the {{ic|~/.gnupg/gpg-agent.conf}} file:<br />
<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
enable-ssh-support<br />
}}<br />
<br />
Next, make sure that ''gpg-agent'' is always started. Use either the [[#Start gpg-agent with systemd user|systemd user service]] or add the following to your {{ic|.bashrc}} file:<br />
<br />
{{hc|~/.bashrc|<nowiki><br />
# Start the gpg-agent if not already running<br />
if ! pgrep -x -u "${USER}" gpg-agent >/dev/null 2>&1; then<br />
gpg-connect-agent /bye >/dev/null 2>&1<br />
fi<br />
</nowiki>}}<br />
<br />
Then set {{ic|SSH_AUTH_SOCK}} so that SSH will use ''gpg-agent'' instead of ''ssh-agent'':<br />
<br />
{{hc|~/.bashrc|<nowiki><br />
# Set SSH to use gpg-agent<br />
unset SSH_AGENT_PID<br />
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then<br />
export SSH_AUTH_SOCK="${HOME}/.gnupg/S.gpg-agent.ssh"<br />
fi<br />
</nowiki>}}<br />
<br />
Also set the GPG TTY and refresh the TTY in case user has switched into an X session. Example:<br />
<br />
{{Expansion|Not clear why this is necessary (even tha man page does not explain it).}}<br />
<br />
{{hc|~/.bashrc|<nowiki><br />
# Set GPG TTY<br />
export GPG_TTY=$(tty)<br />
<br />
# Refresh gpg-agent tty in case user switches into an X session<br />
gpg-connect-agent updatestartuptty /bye >/dev/null<br />
</nowiki>}}<br />
<br />
Once ''gpg-agent'' is running you can use ''ssh-add'' to approve keys, following the same steps as for [[SSH keys#ssh-agent|ssh-agent]]. The list of approved keys is stored in the {{ic|~/.gnupg/sshcontrol}} file. Once your key is approved, you will get a ''pinentry'' dialog every time your passphrase is needed. You can control passphrase caching in the {{ic|~/.gnupg/gpg-agent.conf}} file. The following example would have ''gpg-agent'' cache your keys for 3 hours:<br />
<br />
{{hc|~/.gnupg/gpg-agent.conf|<br />
default-cache-ttl-ssh 10800<br />
}}<br />
<br />
== Smartcards ==<br />
<br />
GnuPG uses ''scdaemon'' as an interface to your smartcard reader, please refer to the [[man page]] for details.<br />
<br />
=== GnuPG only setups ===<br />
<br />
{{Note| To allow scdaemon direct access to USB smarcard readers the optional dependency {{Pkg|libusb-compat}} have to be installed}}<br />
<br />
If you do not plan to use other cards but those based on GnuPG, you should check the {{Ic|reader-port}} parameter in {{ic|~/.gnupg/scdaemon.conf}}. The value '0' refers to the first available serial port reader and a value of '32768' (default) refers to the first USB reader.<br />
<br />
=== GnuPG with PSCD-Lite ===<br />
<br />
{{Note|{{Pkg|pcsclite}} and {{Pkg|ccid}} have to be installed, and the contained [[systemd#Using units|systemd]] service {{ic|pcscd.service}} has to be running, or the socket {{ic|pscd.socket}} has to be listening.}}<br />
<br />
PSCD-Lite is a daemon which handles access to smartcard (SCard API). If GnuPG's scdaemon fails to connect the smartcard directly (e.g. by using its integrated CCID support), it will fallback and try to find a smartcard using the PSCD-Lite driver.<br />
<br />
==== Always use PSCD-Light ====<br />
<br />
If you are using any smartcard with an opensc driver (e.g.: ID cards from some countries) you should pay some attention to GnuPG configuration. Out of the box you might receive a message like this when using {{Ic|gpg --card-status}}<br />
<br />
gpg: selecting openpgp failed: ec=6.108<br />
<br />
By default, scdaemon will try to connect directly to the device. This connection will fail if the reader is being used by another process. For example: the pcscd daemon used by OpenSC. To cope with this situation we should use the same underlying driver as opensc so they can work well together. In order to point scdaemon to use pcscd you should remove {{Ic|reader-port}} from {{ic|~/.gnupg/scdaemon.conf}}, specify the location to {{ic|libpcsclite.so}} library and disable ccid so we make sure that we use pcscd:<br />
<br />
{{hc|~/.gnupg/scdaemon.conf|<nowiki><br />
pcsc-driver /usr/lib/libpcsclite.so<br />
card-timeout 5<br />
disable-ccid<br />
</nowiki>}}<br />
<br />
Please check {{Ic|man scdaemon}} if you do not use OpenSC.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Different algorithm ===<br />
<br />
You may want to use stronger algorithms:<br />
<br />
{{hc|~/.gnupg/gpg.conf|<br />
...<br />
<br />
personal-digest-preferences SHA512<br />
cert-digest-algo SHA512<br />
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed<br />
personal-cipher-preferences TWOFISH CAMELLIA256 AES 3DES<br />
}}<br />
<br />
In the latest version of GnuPG, the default algorithms used are SHA256 and AES, both of which are secure enough for most people. However, if you are using a version of GnuPG older than 2.1, or if you want an even higher level of security, then you should follow the above step.<br />
<br />
=== Encrypt a password ===<br />
<br />
It can be useful to encrypt some password, so it will not be written in clear on a configuration file. A good example is your email password.<br />
<br />
First create a file with your password. You '''need''' to leave '''one''' empty line after the password, otherwise gpg will return an error message when evaluating the file.<br />
<br />
Then run:<br />
<br />
$ gpg -e -a -r ''<user-id>'' ''your_password_file''<br />
<br />
{{ic|-e}} is for encrypt, {{ic|-a}} for armor (ASCII output), {{ic|-r}} for recipient user ID.<br />
<br />
You will be left with a new {{ic|''your_password_file''.asc}} file.<br />
<br />
=== Revoking a key ===<br />
<br />
{{Warning|<br />
*Anybody having access to your revocation certificate can revoke your key, rendering it useless.<br />
*Key revocation should only be performed if your key is compromised or lost, or you forget your passphrase.}}<br />
<br />
Revocation certificates are automatically generated for newly generated keys, although one can be generated manually by the user later. These are located at {{ic|~/.gnupg/openpgp-revocs.d/}}. The filename of the certificate is the fingerprint of the key it will revoke.<br />
<br />
To revoke your key, simply import the revocation certificate:<br />
<br />
$ gpg --import ''<fingerprint>''.rev<br />
<br />
Now update the keyserver:<br />
<br />
$ gpg --keyserver subkeys.pgp.net --send ''<userid>''<br />
<br />
=== Change trust model ===<br />
<br />
By default GnuPG uses the [[Wikipedia::Web of Trust|Web of Trust]] as the trust model. You can change this to [[Wikipedia::Trust on First|Trust on First]] Use by adding {{ic|1=--trust-model=tofu}} when adding a key or adding this option to your GnuPG configuration file. More details are in [https://lists.gnupg.org/pipermail/gnupg-devel/2015-October/030341.html this email to the GnuPG list].<br />
<br />
=== Hide all recipient id's ===<br />
<br />
By default the recipient's key ID is in the encrypted message. This can be removed at encryption time for a recipient by using {{ic|hidden-recipient ''<user-id>''}}. To remove it for all recipients add {{ic|throw-keyids}} to your configuration file. This helps to hide the receivers of the message and is a limited countermeasure against traffic analysis. (Using a little social engineering anyone who is able to decrypt the message can check whether one of the other recipients is the one he suspects.) On the receiving side, it may slow down the decryption process because all available secret keys must be tried (''e.g.'' with {{ic|--try-secret-key ''<user-id>''}}).<br />
<br />
=== Using caff for keysigning parties ===<br />
<br />
To allow users to validate keys on the keyservers and in their keyrings (i.e. make sure they are from whom they claim to be), PGP/GPG uses he [[Wikipedia::Web of Trust|Web of Trust]]. Keysigning parties allow users to get together in physical location to validate keys. The [[Wikipedia:Zimmermann–Sassaman key-signing protocol|Zimmermann-Sassaman]] key-signing protocol is a way of making these very effective. [http://www.cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html Here] you will find a how-to article.<br />
<br />
For an easier process of signing keys and sending signatures to the owners after a keysigning party, you can use the tool ''caff''. It can be installed from the AUR with the package {{AUR|caff-svn}} or bundled together with other useful tools in the package {{AUR|signing-party-svn}}{{Broken package link|{{aur-mirror|signing-party-svn}}}}.<br />
Either way, there will be a lot of dependencies installing from the AUR. Alternatively you can install them from CPAN with<br />
cpanm Any::Moose<br />
cpanm GnuPG::Interface<br />
<br />
To send the signatures to their owners you need a working [[Wikipedia:Message transfer agent|MTA]]. If you do not have already one, install [[msmtp]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Not enough random bytes available ===<br />
When generating a key, gpg can run into this error:<br />
Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy!<br />
To check the available entropy, check the kernel parameters:<br />
cat /proc/sys/kernel/random/entropy_avail<br />
A healthy Linux system with a lot of entropy available will have return close to the full 4,096 bits of entropy. If the value returned is less than 200, the system is running low on entropy. <br />
<br />
To solve it, remember you do not often need to create keys and best just do what the message suggests (e.g. create disk activity, move the mouse, edit the wiki - all will create entropy). If that does not help, check which service is using up the entropy and consider stopping it for the time. If that is no alternative, see [[Random number generation#Faster alternatives]].<br />
<br />
=== su ===<br />
<br />
When using {{Ic|pinentry}}, you must have the proper permissions of the terminal device (e.g. {{Ic|/dev/tty1}}) in use. However, with ''su'' (or ''sudo''), the ownership stays with the original user, not the new one. This means that pinentry will fail, even as root. The fix is to change the permissions of the device at some point before the use of pinentry (i.e. using gpg with an agent). If doing gpg as root, simply change the ownership to root right before using gpg:<br />
<br />
chown root /dev/ttyN # where N is the current tty<br />
<br />
and then change it back after using gpg the first time. The equivalent is likely to be true with {{Ic|/dev/pts/}}.<br />
<br />
{{Note|The owner of tty ''must'' match with the user for which pinentry is running. Being part of the group {{Ic|tty}} '''is not''' enough.}}<br />
<br />
=== Agent complains end of file ===<br />
<br />
The default pinentry program is pinentry-gtk-2, which needs a DBus session bus to run properly. See [[General troubleshooting#Session permissions]] for details.<br />
<br />
Alternatively, you can use {{ic|pinentry-qt}}. See [[#pinentry]].<br />
<br />
=== KGpg configuration permissions ===<br />
<br />
There have been issues with {{Pkg|kdeutils-kgpg}} being able to access the {{ic|~/.gnupg/}} options. One issue might be a result of a deprecated ''options'' file, see the [https://bugs.kde.org/show_bug.cgi?id=290221 bug] report.<br />
<br />
Another user reported that ''KGpg'' failed to start until the {{ic|~/.gnupg}} folder is set to {{ic|drwxr-xr-x}} permissions. If you require this work-around, ensure that the directory contents retain {{ic|-rw-------}} permissions! Further, report it as a bug to the [https://bugs.kde.org/buglist.cgi?quicksearch=kgpg developers].<br />
<br />
=== Conflicts between gnome-keyring and gpg-agent ===<br />
<br />
{{Accuracy|See [[#GPG_AGENT_INFO]]}}<br />
<br />
While the Gnome keyring implements a GPG agent component, as of GnuPG version 2.1, GnuPG ignores the {{ic|GPG_AGENT_INFO}} environment variable, so that Gnome keyring can no longer be used as a GPG agent.<br />
<br />
However, since version 0.9.6 the package {{Pkg|pinentry}} provides the {{Ic|pinentry-gnome3}} program. You may set the following option in your {{Ic|gpg-agent.conf}} file<br />
pinentry-program /usr/bin/pinentry-gnome3<br />
in order to make use of that pinentry program.<br />
<br />
Since version 0.9.2 all pinentry programs can be configured to optionally save a passphrase with libsecret. For example, when the user is asked for a passphrase via {{Ic|pinentry-gnome3}}, a checkbox is shown whether to save the passphrase using a password manager. Unfortunately, the package {{Pkg|pinentry}} does not have this feature enabled (see {{Bug|46059}} for the reasons). You may use {{AUR|pinentry-libsecret}} as a replacement for it, which has support for libsecret enabled.<br />
<br />
=== mutt and gpg ===<br />
<br />
To be asked for your GnuPG password only once per session as of GnuPG 2.1, see [https://bbs.archlinux.org/viewtopic.php?pid=1490821#p1490821 this forum thread].<br />
<br />
=== "Lost" keys, upgrading to gnupg version 2.1 ===<br />
<br />
When {{ic|gpg --list-keys}} fails to show keys that used to be there, and applications complain about missing or invalid keys, some keys may not have been migrated to the new format.<br />
<br />
Please read [http://jo-ke.name/wp/?p=111 GnuPG invalid packet workaround]. Basically, it says that there is a bug with keys in the old {{ic|pubring.gpg}} and {{ic|secring.gpg}} files, which have now been superseded by the new {{ic|pubring.kbx}} file and the {{ic|private-keys-v1.d/}} subdirectory and files. Your missing keys can be recovered with the following commnads:<br />
<br />
$ cd<br />
$ cp -r .gnupg gnupgOLD<br />
$ gpg --export-ownertrust > otrust.txt<br />
$ gpg --import .gnupg/pubring.gpg<br />
$ gpg --import-ownertrust otrust.txt<br />
$ gpg --list-keys<br />
<br />
=== gpg hanged for all keyservers (when trying to receive keys) ===<br />
<br />
If gpg hanged with a certain keyserver when trying to receive keys, you might need to kill dirmngr in order to get access to other keyservers which are actually working, otherwise it might keeping hanging for all of them.<br />
<br />
=== Smartcard not detected ===<br />
<br />
Your user might not have the permission to access the smartcard which results in a {{ic|card error}} to be thrown, even though the card is correctly set up and inserted.<br />
<br />
One possible solution is to add a new group {{ic|scard}} including the users who need access to the smartcard.<br />
<br />
Then use an [[Udev#Writing_udev_rules|udev]] rule, similar to the following:<br />
{{hc|/etc/udev/rules.d/71-gnupg-ccid.rules|<nowiki><br />
ACTION=="add", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="1050", ENV{ID_MODEL_ID}=="0116|0111", MODE="660", GROUP="scard"<br />
</nowiki>}}<br />
One needs to adapt VENDOR and MODEL according to the {{ic|lsusb}} output, the above example is for a YubikeyNEO.<br />
<br />
== See also ==<br />
<br />
* [https://gnupg.org/ GNU Privacy Guard Homepage]<br />
* [https://fedoraproject.org/wiki/Creating_GPG_Keys Creating GPG Keys (Fedora)]<br />
* [https://wiki.debian.org/Subkeys OpenPGP subkeys in Debian]<br />
* [http://blog.sanctum.geek.nz/series/linux-crypto/ A more comprehensive gpg Tutorial]<br />
* [https://help.riseup.net/en/security/message-security/openpgp/gpg-best-practices gpg.conf recommendations and best practices]<br />
* [https://github.com/ioerror/torbirdy/blob/master/gpg.conf Torbirdy gpg.conf]<br />
* [https://www.reddit.com/r/GPGpractice/ /r/GPGpractice - a subreddit to practice using GnuPG.]</div>Ritka