Ignorer les vérifications de signature GPG pour un seul référentiel

J'ai lu l'article suivant: Comment puis-je contourner / ignorer les contrôles de signature gpg d'apt?

Il décrit comment configurer aptpour ne pas vérifier les signatures des packages du tout .

Cependant, j'aimerais limiter les effets de ce paramètre à un seul référentiel (dans ce cas hébergé localement).

Autrement dit, tous les référentiels officiels doivent utiliser la vérification de signature GPG comme d'habitude, à l' exception du référentiel local .

Comment pourrais-je m'y prendre?

À défaut, quel serait l'avantage (du point de vue de la sécurité) de signer les packages lors d'une construction automatisée (certains méta-packages et quelques programmes), puis de respecter toutes lesapt prescriptions sécurisées ? Après tout, l'hôte avec le référentiel serait également celui sur lequel réside la clé GPG secrète.

apt repository

— 0xC0000022L
source

À mon avis, la signature automatique à l'aide d'une clé en ligne, bien que loin d'être idéale, serait strictement préférable à l'absence de signature. Il serait également beaucoup plus facile à configurer (pas besoin de configurer chaque client pour annuler les contrôles) et beaucoup plus facile à passer ultérieurement à une meilleure configuration si vous le souhaitez.

— Celada

@Celada: est-ce une opinion (que c'est "strictement meilleure") ou y a-t-il une raison pour votre déclaration? Je demande, parce que jusqu'à présent, je ne vois pas pourquoi cela améliorerait la sécurité ou tout autre aspect. La seule fois où cela serait quelque peu bénéfique, ce serait si j’avais l’intention de publier mon rapport après tout, non?

— 0xC0000022L

Je garde cette opinion de manière rationnelle :-) Si le référentiel est signé, au moins les méchants doivent-ils obtenir la clé de signature, que vous conserverez probablement à un seul endroit et probablement sur une boîte de dev, ou du moins non lisible par le Serveur HTTP. Sinon, il n'y a pas de protection du tout. En d'autres termes, je veux simplement dire qu'il n'y a pas d'inconvénient à la signature, vous pouvez donc aussi bien signer, même si l'avantage n'est que minuscule. Et comme ce serait plus facile à installer, c'est ce que je choisirais.

— Celada

@Celada: il s'agit d'un référentiel réservé à l'usage local. Qui serait en mesure d'y accéder. Cas d'utilisation: un hôte avec des conteneurs invités. L'hôte et les conteneurs auront accès. Pas d'accès public prévu. Mais j'imagine que je vais attendre un peu plus longtemps pour une réponse et tenter l'inévitable (signature).

— 0xC0000022L

Très bien, nous verrons si quelqu'un connaît la réponse à votre question. Je ne sais pas quel outil vous comptez utiliser pour générer le repo, mais je vous recommande reprepro . De nombreux autres outils tels que dput(ou tout ce que Debian utilise lui-même) sont très élaborés et semblent être une surexploitation considérable pour un référentiel ad hoc local. repreprose chargera de générer automatiquement le référentiel avec la structure de répertoire correcte et les fichiers d’index sans avoir à installer un serveur de base de données volumineux ... et signera également le résultat sans travail supplémentaire de votre part.

— Celada

Vous pouvez définir des options dans votre sources.list:

deb [trusted=yes] http://localmachine/debian wheezy main

L' trustedoption est ce qui désactive la vérification de GPG. Voir man 5 sources.listpour plus de détails.

Note: ceci a été ajouté dans apt 0.8.16 ~ exp3. Donc, c'est en wheezy (et bien sûr jessie), mais pas presser.

— derobert
source

merci un tas. C'était exactement ce que je cherchais. J'espère 1.0.1ubuntu2.7avoir déjà cette fonctionnalité, étant donné son numéro de version.

— 0xC0000022L le

@ 0xC0000022L oui, il le devrait.

— derobert

C’est définitivement la meilleure réponse si vous devez à plusieurs reprises accéder à un référentiel non signé. Des réponses actualisées à l’autre question liée à la question initiale vous indiquent ici comment procéder temporairement par référentiel.

— dragon788

Pour vous assurer que vous voyez un avertissement lorsque vous utilisez un référentiel non sécurisé, utilisez plutôt allow-insecure = yes, comme ci-dessous.

deb [ allow-insecure=yes ] ...

— Naresh Mehta
source

Intéressant, merci pour votre réponse. Une petite mais importante différence en effet.

— 0xC0000022L