हमारे पास एक निजी डेबियन रिपॉजिटरी है जिसे वर्षों पहले एक पुराने सिस्टम एडमिन द्वारा स्थापित किया गया था। पैकेजों पर पुरानी कुंजी, 7610DDDE (जिसे मुझे रद्द करना पड़ा) द्वारा हस्ताक्षरित किया गया था, जैसा कि रेपो सर्वर पर रूट उपयोगकर्ता के लिए यहां दिखाया गया है।

# gpg --list-keys
/root/.gnupg/pubring.gpg
------------------------
pub   1024D/2D230C5F 2006-01-03 [expired: 2007-02-07]
uid                  Debian Archive Automatic Signing Key (2006)  <[email protected]>

pub   1024D/7610DDDE 2006-03-03 [revoked: 2016-03-31]
uid                  Archive Maintainer <[email protected]>

pub   4096R/DD219672 2016-04-18
uid                  Archive Maintainer <[email protected]>

नीचे दिए गए सभी कमांड रूट यूजर के रूप में हैं। मैंने हस्ताक्षर करने के लिए स्पष्ट रूप से बनाई गई नई उप कुंजी का उपयोग करने के लिए भंडार/conf/वितरण फ़ाइल को संशोधित किया:

Architectures: i386 amd64 source
Codename: unstable
Components: main
...
SignWith: DD219672

लेकिन जब मैं पैकेज को अपडेट करने के लिए dput का उपयोग करता हूं तो मुझे मिलता है

Could not find any key matching 'DD219672'!
ERROR: Could not finish exporting 'unstable'!
This means that from outside your repository will still look like before (and
should still work if this old state worked), but the changes intended with this
call will not be visible until you call export directly (via reprepro export)

और जब मैं सीधे रेप्रेप्रो निर्यात चलाता हूं तो मुझे मिलता है:

# reprepro -V export unstable
Exporting unstable...
 generating main/Contents-i386...
 generating main/Contents-amd64...
Could not find any key matching 'DD219672'!
ERROR: Could not finish exporting 'unstable'!

मैंने गुगल किया और कुछ पुराने धागे पाए जो उचित gnupg निर्देशिका खोजने के लिए reprepro के साथ संभावित समस्या का संकेत देते थे ... इसलिए मैंने इसे उपरोक्त समान परिणामों के साथ करने की कोशिश की:

# GNUPGHOME=/root/.gnupg reprepro -V export unstable

एक थ्रेड ने एक डमी फ़ाइल पर हस्ताक्षर करके कुंजी का परीक्षण करने का सुझाव दिया जो ठीक काम कर रही थी ... कम से कम इसमें कोई त्रुटि नहीं थी और मैं समाप्त होने के बाद 576 बाइट bla.gpg फ़ाइल के साथ समाप्त हुआ।

# touch bla
# gpg -u DD219672 --sign bla

रेप्रेप्रो मैन पेज यह भी सुझाव देता है "यदि हस्ताक्षर करने में कोई समस्या है, तो आप यह देखने के लिए gpg --list-secret-keys मान का प्रयास कर सकते हैं कि gpg मूल्य की व्याख्या कैसे कर सकता है। यदि वह आदेश किसी भी कुंजी या एकाधिक को सूचीबद्ध नहीं करता है, तो खोजने का प्रयास करें कुछ अन्य मूल्य (कीड की तरह), कि gpg अधिक आसानी से एक अद्वितीय कुंजी के साथ जुड़ सकता है।" तो मैंने उसे भी चेक किया और मिला:

# gpg --list-secret-keys DD219672
sec   4096R/DD219672 2016-04-18
uid                  Archive Maintainer <[email protected]>

और अंत में मैं उस sys व्यवस्थापक से संपर्क करने में सक्षम हुआ जिसने पहले हमारे रिप्रो को सेट किया और उसने सुझाव दिया कि बिना पासफ़्रेज़ के एक कुंजी आज़माने की कोशिश करें। इसलिए मैंने एक नई हस्ताक्षर कुंजी बनाई, DD219672, इसे प्रकाशित किया, उपरोक्त चरणों के माध्यम से फिर से चला गया लेकिन उसी परिणाम के साथ।

आज, मैन पेजों को अधिक पढ़ने और अध्ययन करने के बाद और यह देखते हुए कि जब मैं रेप्रेप्रो चलाता हूं तो पीजीपी-एजेंट स्वचालित रूप से शुरू हो जाता है, मैंने थोड़ी देर के लिए इसका पीछा करने का फैसला किया।

मैंने gpg-agent.conf के साथ जोड़ा

debug-level 7
log-file    /root/gpg.agent.log
debug-all

और मैं लॉग में देख सकता हूं कि gpg-agent को चाबियाँ नहीं मिल रही हैं

2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK Pleased to meet you, process 18903
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- RESET
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION ttyname=/dev/pts/0
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION ttytype=xterm-256color
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- GETINFO version
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> D 2.1.11
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION allow-pinentry-notify
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION agent-awareness=2.1.0
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- AGENT_ID
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> ERR 67109139 Unknown IPC command <GPG Agent>
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- HAVEKEY C2C5C59E5E90830F314ABB66997CCFAACC5DEA2F 416E8A33354912FF4843D52AAAD43FBF206252D9 8CE77065EA6F3818A4975072C8341F32CB7B0EF0
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> ERR 67108881 No secret key <GPG Agent>
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- [eof]

मैं अब तक यह पता लगाने में असमर्थ रहा हूं कि gpg-agent को वह कुंजी कहां मिल रही है जो इसे HAVKEY में सूचीबद्ध करती है और हमारे अद्यतन पैकेजों पर हस्ताक्षर करने के लिए नई कुंजी, DD219672 को खोजने के लिए इसे सही दिशा में कैसे इंगित किया जाए।

answer

मुझे भी यही समस्या थी, और बहुत निराशा के बाद आखिरकार पता चला कि क्या हो रहा था।

repreproउपकरण का उपयोग करता है gpgme है, जो पर आधारित है gnupg2इसकी एक हालिया रिलीज ने गुप्त चाबी के छल्ले को संभालने के तरीके को बदल दिया: https://www.gnupg.org/faq/whats-new-in-2.1.html

gpg used to keep the public key pairs in two files: pubring.gpg and secring.gpg ... With GnuPG 2.1 this changed ... To ease the migration to the no-secring method, gpg detects the presence of a secring.gpg and converts the keys on-the-fly to the the key store of gpg-agent (this is the private-keys-v1.d directory below the GnuPG home directory (~/.gnupg)). This is done only once and an existing secring.gpg is then not anymore touched by gpg. This allows co-existence of older GnuPG versions with GnuPG 2.1. However, any change to the private keys using the new gpg will not show up when using pre-2.1 versions of GnuPG and vice versa.

इस प्रकार, यदि आप gpg के साथ एक नई कुंजी बनाते हैं, तो gpg2 इसे नहीं देखेगा, और इसके विपरीत।

मेरे लिए काम करने वाले त्वरित सुधार:

gpg --export-secret-keys | gpg2 --import -

और अगर आपको दूसरी तरफ जाने की ज़रूरत है, तो निश्चित रूप से:

gpg2 --export-secret-keys | gpg --import -

आपके सेटअप के आधार पर, आप जोड़ना चाह/चाह सकते हैं --export-secret-subkeys

उपरोक्त करने के बाद, repreproमेरी नई कुंजी के साथ ठीक से काम किया।

मेरे लिए मुद्दा यह था कि मैंने उपयोगकर्ता के रूप में कुंजियाँ बनाईं और reprepro को root के रूप में चलाया

क्या हुआ कि मेरे द्वारा "बिना sudo" जेनरेट की जाने वाली चाबियां मेरे स्थानीय pubring.gpg. जब मैं दौड़ता sudo reprepro ...हूं तो मैं इसे रूट के रूप में चलाता हूं और इसलिए यह रूट में कुंजी खोजने की कोशिश करता है pubring.gpgऔर स्पष्ट रूप से एक नहीं मिलता है।

समाधान सभी gpgकमांड को रूट (eq। sudo -iऔर फिर gpg --gen-key) के रूप में चलाना था सुनिश्चित करें कि जब आप दौड़ते हैं sudo gpg --list-keysतो आपको अपनी वांछित कुंजियाँ और रेखा दिखाई देती है /root/.gnupg/pubring.gpg

उम्मीद है की वो मदद करदे!