میرورهای APT چگونه کار می‌کنند و اعتماد به مخزن از کجا می‌آید؟

اگر نشانی دانلود بسته‌های دبیان را به یک سرور داخل شرکت تغییر دهیم، چرا APT باید به آن اعتماد کند؟ آیا بودن در شبکهٔ داخلی کافی است؟ آیا هر میرور کلید مخصوص خودش را دارد؟ پاسخ به این پرسش‌ها به تفاوت میان «محل دریافت فایل» و «مرجع امضاکنندهٔ محتوا» وابسته است.

در این نوشته، مسیر انتشار بسته تا میرور و کلاینت را بررسی می‌کنیم و می‌بینیم کدام تغییر فقط نشانی دانلود را عوض می‌کند و کدام تغییر، مرز اعتماد تازه‌ای می‌سازد.

مخزن، میرور و کش یک چیز نیستند#

در دنیای APT اصطلاح رایج repository یا archive است. ممکن است در تیم زیرساخت به آن «رجیستری بسته» بگوییم؛ اما پروتکل آن همان رجیستری ایمیج کانتینر نیست. کلاینت APT می‌تواند اطلاعات و بسته‌ها را از فایل‌های ایستای روی وب‌سرور دریافت کند.

میرور را می‌توان پیش از درخواست کلاینت‌ها همگام کرد؛ کش معمولاً با درخواست‌ها پر می‌شود و به‌تنهایی تضمین نمی‌کند همهٔ بسته‌های لازم برای نصب آفلاین موجود باشند. ابزارهایی مانند aptly نیز می‌توانند از مخزن خارجی بسته بگیرند و مجموعهٔ انتخاب‌شده را دوباره منتشر کنند. مدل دادهٔ aptly

درخواست کلاینت روی شبکه چه شکلی است؟#

برای منبعی با URI برابر https://mirror.example.org/debian، انتشار trixie، مؤلفهٔ main و معماری amd64، مسیرها به‌طور مفهومی چنین‌اند:

Client
  |
  +-- GET /debian/dists/trixie/InRelease
  +-- GET /debian/dists/trixie/main/binary-amd64/Packages.xz
  +-- GET /debian/pool/.../package_version_amd64.deb

درخواست واقعی فهرست ممکن است از مسیر By-Hash یا قالب فشردهٔ دیگری استفاده کند. apt update اطلاعات انتشار و فهرست‌ها را تازه می‌کند؛ هنگام نصب، APT مسیر فایل بسته را از فهرست معتبر به دست می‌آورد. وب‌سرور لازم نیست حل وابستگی انجام دهد؛ این تصمیم روی کلاینت گرفته می‌شود. راهنمای منابع APT ، راهنمای apt-get

میرور چگونه همگام می‌شود؟#

در میرور بدون تغییر، فایل‌های بسته و متادیتای امضاشده از بالادست کپی می‌شوند. ترتیب همگام‌سازی مهم است: اگر فهرست جدید پیش از بسته‌هایی که معرفی می‌کند در دسترس قرار بگیرد، کلاینت با 404 روبه‌رو می‌شود. اگر فهرست و Release متعلق به دو لحظهٔ متفاوت باشند، ممکن است خطای هش ببیند.

دبیان برای ساخت میرور استفاده از مجموعه‌ابزار ftpsync را توضیح می‌دهد؛ این فرایند صرفاً اجرای یک کپی دلخواه روی پوشه‌ها نیست. انتخاب بالادست مناسب، همگام‌سازی منظم و جلوگیری از اجرای هم‌زمان چند sync بخشی از نگهداری میرور است. راهنمای رسمی ساخت میرور دبیان

By-Hash با قراردادن هش مورد انتظار در مسیر فهرست، بخشی از مشکل تغییر هم‌زمان متادیتا را حل می‌کند. با این حال، همگام‌سازی ناقص، کمبود فضای دیسک یا نبودن فایل بسته همچنان می‌تواند نصب را شکست دهد. گزینهٔ By-Hash

اعتماد به دامنه نیست؛ اعتماد به کلید ناشر است#

در حالت معمول، APT این زنجیره را بررسی می‌کند:

Trusted public key on client
           |
           v
Signature on InRelease / Release
           |
           v
Hash of Packages index
           |
           v
Hash of downloaded .deb

امضای معتبر نشان می‌دهد متادیتا با کلید خصوصی متناظر تولید شده است. هش‌ها متادیتا را به فهرست و فایل بسته متصل می‌کنند. APT معمولاً امضای مستقل هر .deb را بررسی نمی‌کند. تغییر محتوای بسته روی میرور، بدون امکان ساخت زنجیرهٔ امضای معتبر، هنگام اعتبارسنجی آشکار می‌شود. این مدل تضمین نمی‌کند کد ناشر بی‌اشکال باشد. مدل امنیتی apt-secure

بنابراین برای کپی بدون تغییر مخزن رسمی، به کلید خصوصی دبیان یا اوبونتو نیاز نداریم. میرور همان امضای بالادست را تحویل می‌دهد و کلاینت آن را با کلید رسمی بررسی می‌کند. تغییر URI به‌تنهایی مستلزم اعتماد به یک کلید جدید نیست.

کلیدهای رسمی ابتدا از کجا آمده‌اند؟#

در دبیان، کلیدهای آرشیو با بستهٔ debian-archive-keyring توزیع می‌شوند. صفحهٔ رسمی ftp-master اطلاعات کلیدها و اثرانگشت آن‌ها را منتشر می‌کند. این کلیدها با کلیدهای شخصی همهٔ نگه‌دارندگان یکسان نیستند؛ امضای بارگذاری نگه‌دارنده و امضای آرشیوی که کلاینت مصرف می‌کند دو مرحلهٔ متفاوت‌اند. کلیدهای امضای آرشیو دبیان

در اوبونتو، بستهٔ ubuntu-keyring ریشهٔ اعتماد آرشیو را در نصب اولیه فراهم می‌کند. کلید جدید باید از مسیری که از قبل مورداعتماد است توزیع شود. این اعتماد در نهایت به نصب اولیهٔ معتبر، ایمیج سازمانی مورداعتماد یا راه‌اندازی اولیه توسط مدیر سیستم برمی‌گردد؛ دانلود یک کلید از همان سرور ناشناس، به‌تنهایی هویت آن را اثبات نمی‌کند. تأیید اصالت آرشیو اوبونتو

به همین دلیل، پاسخ دقیق به «چه کسی مخزن را مورداعتماد می‌کند؟» این است: توزیع، کلیدهای رسمی را در نصب اولیه قرار می‌دهد؛ برای منبع ثالث، مدیر سیستم باید کلید و سیاست منبع را آگاهانه اضافه کند.

میرور رسمی با مخزن مورداعتماد چه تفاوتی دارد؟#

قرارگرفتن در فهرست میرورهای دبیان موضوعی دربارهٔ ارائهٔ سرویس میرور است. کلاینت در هر نصب به این فهرست مراجعه نمی‌کند تا اجازهٔ رمزنگاری صادر شود. یک میرور خصوصی هم می‌تواند محتوای رسمی را با همان امضای معتبر ارائه کند؛ یک دامنهٔ مشهور هم اگر متادیتای نامعتبر تحویل دهد نباید اعتبارسنجی را پشت سر بگذارد.

HTTPS و امضای آرشیو نیز دو نقش جدا دارند: TLS ارتباط با سرور و محرمانگی مسیر انتقال را فراهم می‌کند؛ امضای آرشیو اصالت محتوای منتشرشده را بررسی می‌کند. داشتن گواهی TLS معتبر، مجوز امضای بسته‌های اوبونتو نیست. زنجیرهٔ تأیید در اوبونتو

Signed-By دقیقاً چه چیزی را محدود می‌کند؟#

نمونهٔ زیر برای یک کپی بدون تغییر از آرشیو دبیان است؛ نشانی آن آموزشی است:

Types: deb
URIs: https://mirror.example.org/debian
Suites: trixie
Components: main
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

در مقابل، مخزن سازمانیِ دوباره‌امضاشده باید کلید خودش را معرفی کند:

Types: deb
URIs: https://apt.example.org/internal
Suites: internal
Components: main
Signed-By: /etc/apt/keyrings/company-archive.asc

Signed-By تعیین می‌کند کدام کلید مجاز به تأیید آن منبع است. فایل باید برای کاربر _apt خواندنی باشد. این گزینه محدودیت نام بسته ایجاد نمی‌کند: مخزن ثالث ممکن است بسته‌ای هم‌نام با بستهٔ رسمی عرضه کند. تعریف Signed-By

انتخاب میان نسخه‌های چند مخزن به اولویت‌ها و قواعد APT وابسته است. اگر فقط بسته‌های مشخصی باید از منبع داخلی بیایند، سیاست pinning جداگانه لازم است؛ امضای معتبر جایگزین این سیاست نمی‌شود. با apt-cache policy PACKAGE منبع و نامزد نصب را بررسی کنید. سیاست انتخاب نسخه و pinning

وقتی با aptly دوباره منتشر می‌کنیم چه عوض می‌شود؟#

اگر یک بسته را از مخزن حذف، مجموعه‌ای را فیلتر یا snapshotی را با متادیتای تازه منتشر کنیم، امضای قبلی برای Release جدید معتبر نیست. aptly خروجی تازه را با کلید سازمان امضا می‌کند؛ حتی اگر بایت‌های بسته‌ها همان بسته‌های رسمی باشند.

Debian archive -- Debian signature --> aptly import verification
                                              |
                                        selected snapshot
                                              |
Internal repository -- company signature --> internal clients

در این معماری دو مرز داریم: اعتماد aptly به بالادست و اعتماد کلاینت به ناشر داخلی. کلید عمومی بالادست برای بررسی ورودی است؛ کلید خصوصی سازمان برای امضای خروجی. کلاینتی که فقط خروجی را می‌خواند، انتخاب و تازگی مجموعه را به سازمان سپرده است. دریافت و تأیید میرور در aptly ، انتشار snapshot

امضای معتبر لزوماً یعنی تازه‌بودن محتوا نیست#

محتوای قدیمی نیز می‌تواند امضای صحیح داشته باشد. فیلدهایی مانند Date و Valid-Until و بررسی ساعت سیستم به تشخیص بعضی حالت‌های بازپخش یا انقضای متادیتا کمک می‌کنند. همهٔ مخازن سیاست انقضای یکسان ندارند؛ غیرفعال‌کردن بررسی زمان برای رفع خطا می‌تواند مشکل واقعی را پنهان کند. اعتبار زمانی مخزن در sources.list

برای مخزن داخلی باید جداگانه بدانیم آخرین دریافت موفق چه زمانی بوده، چه snapshotی اکنون منتشر است و اصلاحیه‌های امنیتی چقدر عقب افتاده‌اند. انتشار مجدد یک snapshot قدیمی آن را از نظر محتوای نرم‌افزار به‌روز نمی‌کند.

از روی خطا، لایهٔ مشکل را پیدا کنیم#

مخزن داخلی قابل‌اعتماد فقط یک وب‌سرور در شبکهٔ خصوصی نیست. باید روشن باشد چه کسی کلید را کنترل می‌کند، چه محتوایی وارد می‌شود، چگونه منتشر می‌شود و چه کسی مسئول رساندن اصلاحیه‌ها به کلاینت‌هاست.