اوسینت جت · بررسی سابقه پروژه‌های عمومی
اوسینت گیت‌هاب: این حساب پروژه را ساخته یا فقط یک نسخه از آن دارد؟
پروژه‌ای در صفحه گیت‌هاب یک شرکت می‌بینید و با خودتان می‌گویید: «پس این‌ها سازنده‌اش هستند.» هنوز زود است. برای بررسی سهم واقعی، باید از نام حساب عبور کنید و به تغییر مشخصی برسید که آن حساب به پروژه اضافه کرده است.
اول روشن کنید قرار است چه چیزی ثابت شود
فرض کنید یک فروشنده، لینک گیت‌هاب را به‌عنوان نمونه کار می‌فرستد. سؤال شما دقیقاً چیست؟ اینکه پروژه در حساب او قرار دارد؟ اینکه یک قابلیت را نوشته؟ اینکه امروز نگهداری‌اش می‌کند؟ یا اینکه نسخه‌ای از آن روی سرویسش فعال است؟ یک لینک به‌تنهایی جواب همه این سؤال‌ها را نمی‌دهد.
ادعای فروشنده را با همان عبارت خودش ثبت کنید. اگر نوشته «پروژه ما»، از طرف او اضافه نکنید «تمام کد را از صفر ساخته‌ایم». برای یک بررسی قابل انجام، یک قابلیت، فایل یا نسخه مشخص لازم دارید. اگر ادعا مبهم است، همین ابهام بخشی از نتیجه است.
مخزن، نسخه مادر و تغییر تازه را قاطی نکنید
مخزن یا Repository محل نگهداری فایل‌ها و سابقه تغییرات پروژه است. Fork یک مخزن جداست که کارش را از روی نسخه پروژه دیگری شروع می‌کند. گیت‌هاب معمولاً پیوند مخزن مادر یا upstream را زیر نام چنین پروژه‌ای نشان می‌دهد؛ جزئیات در راهنمای رسمی فورک آمده است.
فورک‌بودن ایراد نیست. مسئله این است که سهم تازه به‌درستی معرفی شود. حتی یک اصلاح کوچک می‌تواند ارزشمند باشد؛ همان‌طور که داشتن هزاران تغییر قدیمی در سابقه، به معنی نوشتن آن‌ها توسط صاحب فعلی این نسخه نیست. از طرف دیگر، نبودن برچسب فورک هم به‌تنهایی اصالت تمام پروژه را ثابت نمی‌کند.
| چیزی که جدا ثبت می‌کنید | مدرک لازم | سؤال مربوط |
|---|---|---|
| مخزن فعلی | نشانی کامل، نام حساب و رابطه‌ای که صفحه نشان می‌دهد | این نسخه کجا قرار دارد؟ |
| پروژه مادر | لینک upstream و نسخه مرتبط | کدام بخش از قبل وجود داشته؟ |
| تغییر مورد بحث | لینک commit و تفاوت قبل و بعد فایل | دقیقاً چه چیزی اضافه شده؟ |
| انتساب تغییر | نام‌های نمایش‌داده‌شده، جزئیات امضا و شاهد عمومی مرتبط | نسبت‌دادن این تغییر به ادعاکننده چه پشتوانه‌ای دارد؟ |
یک تغییر را بخوانید؛ تعداد تغییرها را نشمارید
در تاریخچه فایل مربوط، تغییر مرتبط با ادعا را پیدا کنید. Commit یک ثبت از تغییرات پروژه است. Diff نمای مقایسه‌ای است که نشان می‌دهد چه خط‌هایی اضافه یا حذف شده‌اند. تفاوت این دو را ساده ببینید: اولی نشانی یک تغییر را می‌دهد؛ دومی کمک می‌کند خود تغییر را بفهمید.
آیا منطق تازه‌ای نوشته شده یا فقط نام یک دکمه عوض شده است؟ آیا تغییر مربوط به راهنماست یا خود قابلیت؟ چند خط اطراف را هم بخوانید. اگر فهم نتیجه به اجرای برنامه نیاز دارد، در گزارش بنویسید این بخش آزمایش نشده است. خواندن کد، عملکرد واقعی یا امنیت آن را تأیید نمی‌کند؛ برای این بررسی لازم نیست برنامه ناشناس نصب و اجرا کنید.
برای ارجاع، لینک همان commit و نسخه همان فایل را نگه دارید. طبق راهنمای پیوند ثابت گیت‌هاب، کلید Y در نمای فایل، لینک را به نسخه مشخص آن تبدیل می‌کند. لینک یک شاخه مثل main ممکن است بعداً محتوای دیگری نشان دهد. پیوند نسخه ثابت هم تضمین نمی‌کند که مخزن برای همیشه قابل دسترس بماند.
نام نویسنده و نشان Verified را درست بخوانید
نام ثبت‌شده برای نویسنده در Git قابل تنظیم است و لزوماً همان نام حساب گیت‌هاب نیست. پس صرف دیدن یک نام آشنا، هویت فرد را اثبات نمی‌کند. این تفاوت در مستند رسمی نام کاربری Git توضیح داده شده است.
نشان Verified به بررسی امضای یک commit مربوط است؛ تأیید کیفیت برنامه، صحت توضیحات یا سمت شغلی فرد نیست. جزئیات نشان را بخوانید و همان را ثبت کنید. گیت‌هاب سابقه بررسی موفق امضا را در شبکه مخزن نگه می‌دارد؛ از این نشان، تأیید تازه‌ای درباره رابطه امروز فرد و شرکت استخراج نکنید. منبع: راهنمای بررسی امضا.
تمرین: سابقه طولانی، تغییر یک‌خطی
مثال کاملاً ساختگی برای آموزش. فروشنده‌ای «فانوس تقویم» را موتور زمان‌بندی خودش معرفی می‌کند. در مخزن، لینک پروژه مادر دیده می‌شود. قابلیت زمان‌بندی در نسخه مادر وجود دارد؛ تغییر معرفی‌شده در نسخه فروشنده فقط نشانی تماس را در فایل راهنما عوض کرده است. این سناریو درباره شرکت واقعی یا آزمایش محصول اوسینت جت نیست.
نتیجه قابل دفاع چنین است: «در نسخه‌های بررسی‌شده، قابلیت زمان‌بندی از پروژه مادر آمده است. تغییر مورد استناد، اطلاعات تماس را عوض می‌کند و نویسندگی آن قابلیت را نشان نمی‌دهد.» این با جمله «این فروشنده هیچ کاری نکرده» فرق دارد. شاید در جای دیگری کاری انجام داده باشد؛ آن بخش را بررسی نکرده‌ایم.
حالا فرض را عوض کنید: همان تغییر، یک امکان دسترس‌پذیری تازه اضافه کرده است. این بار باید همان سهم مشخص را، در حدی که شواهد انتساب اجازه می‌دهد، به رسمیت بشناسید. بررسی خوب نه اعتبار تمام پروژه را یکجا می‌بخشد و نه سهم واقعی کوچک را نادیده می‌گیرد.
یادداشت نهایی باید قابل پیگیری باشد
ادعای دقیق و محل بیان آن: لینک مخزن و زمان مشاهده: رابطه قابل مشاهده با پروژه مادر: قابلیت یا فایل مورد بررسی: لینک commit و نسخه فایل: تغییر مشاهده‌شده: شواهد انتساب و جزئیات امضا: سهم پشتیبانی‌شده / بخش نامشخص: چیزهایی که آزمایش نکردیم:
اگر نام حساب عوض شده، ابتدا راهنمای تغییر یوزرنیم را ببینید. اگر موضوع بخشی از ارزیابی یک شرکت است، شواهد پروژه را کنار بررسی شرکت نگه دارید؛ یکی جای دیگری را نمی‌گیرد.
برای یک تغییر روشن، همین یادداشت کافی است. وقتی ادعای فنی با چند شرکت، دامنه و نماینده درهم می‌آمیزد، می‌توانید از مسیر درخواست تحقیق تخصصی اوسینت جت سؤال مشخصی مطرح کنید. لینک‌ها و سهم مورد اختلاف را بفرستید تا دامنه بررسی و هزینه روشن شود. بررسی کد اجرایی یا اتصال خودکار به گیت‌هاب را جزو خدمت فرض نکنید.
منتشرشده توسط تحریریه اوسینت جت · ۵ اکتبر ۲۰۲۶
ادامه مسیر اوسینت
سرنخ‌های خام را به یک تحقیق ساختارمند در اوسینت جت تبدیل کنید
برای نتیجه بهتر، فقط به یک سرنخ اکتفا نکنید. شماره تلفن، ایمیل، یوزرنیم، دامنه، نام شرکت، تصویر، شهر، لینک شبکه اجتماعی و توضیح زمینه پرونده را کنار هم قرار دهید تا موتور اطلاعاتی اوسینت جت تحلیل دقیق‌تری بسازد.