GitHub Doğrulanmış Commit Rozetini Kimlik Kanıtı Saymadan Okuma

Rozetin gerçekte neyi kaydettiği

Doğrulanmış commit rozeti bir imza kontrolünün sonucudur, karakter referansı değildir. GitHub’da bir commit’in yanında “Verified” gördüğünüzde, platform size tek ve dar bir şey söylüyordur: o commit’e eklenmiş kriptografik bir imzayı kontrol etti ve kontrol başarılı oldu.

GitHub, imzası başarıyla doğrulanan bir commit’i Verified olarak işaretler. Kaynak

Rozet bir kişiye değil, bir commit’e bağlıdır. Aynı zamanda bugün baktığınız hesap için canlı bir güvenlik göstergesi de değildir. Doğrulama sonucu, belirli bir anda gerçekleşen bir kontrolün tarihsel kaydıdır.

Doğrulama kaydedildikten sonra, kayıt bir imzalama anahtarı iptal edilse veya süresi dolsa bile varlığını sürdürebilir. Kaynak

Bu kalıcılık araştırmacılar için önemlidir. Bir rozet, onu üreten imzalama anahtarı iptal edildikten veya süresi dolduktan sonra bile eski bir commit’te görünür kalabilir. İptal edilmiş bir anahtar rozeti geriye dönük olarak silmez ve süresi dolmuş bir anahtar eski commit’i doğrulanmamış hale getirmez. Yani rozet, kaydedildiği sırada imzanın geçerli olduğunu söyler; anahtarın hâlâ güvenilir olduğunu, hesabın hâlâ güvenli olduğunu veya mevcut hesap sahibinin imzalayan kişiyle aynı olduğunu söylemez.

Adım 1: Üç soruyu ayırın

Birisi bir geliştirici iddiasına kanıt olarak doğrulanmış bir commit’i gösterdiğinde, genellikle üç farklı soruyu birbirine karıştırıyordur. Herhangi bir şeyi değerlendirmeden önce bunları ayırın.

Doğrulanmış bir rozet yalnızca ilk satırı yanıtlar. İkinci ve üçüncü satırlar ayrı kanıt gerektirir. Bu, genel profil aramasının bir kişi hakkında neleri açığa çıkarabileceği ve neleri çıkaramayacağı rehberimizde anlatılan disiplinin aynısıdır: kamusal bir eser bir ipucudur, sonuç değildir.

Adım 2: Sadece rozeti değil, commit’i okuyun

Rozet bir kısayoldur ve kısayollar bağlamı gizler. Commit’in kendisini açın ve doğrulama sonucunun etrafındaki unsurlara bakın.

• Commit yazarı alanı ve işleyen (committer) alanı. Bunlar metadata girdileridir, kodu kimin yazdığının kanıtı değildir. Birçok iş akışında herhangi bir değere ayarlanabilirler.
• Gösterilen imzalama anahtarı. GitHub bir doğrulama sonucunu bir anahtarla ilişkilendirir. Anahtarın bir hesaba, bir kuruluşa veya bir bota ait olarak sunulup sunulmadığını not edin.
• Depo ve dal. Kişisel bir çatalda (fork) bulunan doğrulanmış bir commit, bakımı yapılan bir projeye birleştirilmiş olandan daha az kurumsal ağırlık taşır, ancak hiçbiri istihdamı kanıtlamaz.
• Tarih. Eski bir doğrulanmış commit tarihsel bir veri noktasıdır. Hesabın mevcut güvenlik duruşu hakkında hiçbir şey söylemez.

Bu alanların hiçbiri, tek başına veya birlikte, hesap sahibinin bir biyografide adı geçen kişi olduğunu veya kişinin profilinde belirtilen yerde çalıştığını kanıtlamaz.

Adım 3: Mevcut hesap kontrolünü ayrıca kontrol edin

Doğrulanmış bir commit, bir commit hakkında bir kayıttır. Hesap kontrolü ayrı bir sorudur ve genel sayfalar bunu nadiren doğrudan yanıtlar. Yapabileceğiniz şey tutarlılık ve süreklilik aramaktır.

• Hesabın zaman içindeki genel geçmişini karşılaştırın. Uzun ve tutarlı bir katkı geçmişi bir ipucudur, kanıt değildir.
• Aynı kullanıcı adını veya görünen adı diğer platformlarda arayın. Eşleşen kullanıcı adları bir ipucudur. Hesapların aynı kişiye ait olduğunun kanıtı değildir, çünkü kullanıcı adları platformlar arasında benzersiz değildir ve yeniden kullanılabilir veya ele geçirilebilir.
• Profil metnini, avatarları ve biyografileri hesap sahibinin iddiaları olarak ele alın, doğrulanmış gerçekler olarak değil.

Birisi doğrulanmış bir rozeti, hesabı şu anda kontrol ettiğinin kanıtı olarak sunuyorsa, bu bir kategori hatasıdır. Rozet mevcut oturum açma güvenliğini ölçmez ve sizinle konuşan kişinin hesap sahibi olduğunu doğrulamaz.

Adım 4: Bağımsız kanıt arayın

Bağımsız kanıt, iddiayı ortaya atan aynı hesaptan kaynaklanmayan her şeydir. Örnekler arasında bir kuruluşun kendi yayımladığı ekip üyeleri listesi, bir konferans sitesindeki konuşmacı listesi veya kendi genel kaydına sahip kurumsal bir hesap altında bakımı yapılan bir depo sayılabilir. Bunlar bile kimlik kanıtı değil, destekleyici kanıttır. Sizin işiniz, kombinasyonun ne kadar ağırlık hak ettiğine karar vermektir, kesinlik ilan etmek değil.

Karar tablosu: doğrulanmış bir rozete ne kadar ağırlık verilmeli

Yaygın hatalar

• Rozeti kimlik kontrolü olarak ele almak. Bu bir imza sonucudur, arka plan kontrolü değildir.
• Tarihsel bir rozetin mevcut hesap güvenliğini kanıtladığını varsaymak. Kayıt, anahtar iptal edildikten veya süresi dolduktan sonra da varlığını sürdürebilir, bu yüzden rozet canlı bir durum ışığı değildir.
• Yazar ve işleyen (committer) metadata’sını yazarlıkla karıştırmak. Bu alanlar commit nesnesindeki iddialardır, kodu kimin yazdığına dair doğrulanmış gerçekler değildir.
• Eşleşen kullanıcı adlarını tek bir kişinin kanıtı olarak ele almak. İki platformdaki aynı kullanıcı adı bir ipucudur. Hesapların aynı bireye ait olduğunun kanıtı değildir.
• Bir çataldaki rozeti kurumsal onay olarak okumak. Kişisel bir çataldaki doğrulanmış commit, bir kuruluşun çalışmayı incelediğini veya onayladığını kanıtlamaz.
• İmzasız bir commit’i şüpheli varsaymak. Birçok meşru katkıcı ve iş akışı her commit’i imzalamaz.

Öz denetim kontrol listesi

Doğrulanmış bir rozete dayanan bir geliştirici iddiasını tekrarlamadan önce bu kontrol listesini uygulayın.

1. Commit’i açtım ve yazarı, işleyeni, anahtarı, depoyu ve tarihi not ettim mi?
2. “İmza doğrulandı”yı “hesap kontrolü”nden ve “kimlik veya istihdam”dan ayırdım mı?
3. Anahtarın hâlâ hesapla ilişkili olup olmadığını veya kaydın iptal veya süre sonundan sonra da varlığını sürdürüp sürdüremeyeceğini kontrol ettim mi?
4. Aynı hesaptan kaynaklanmayan en az bir kaynak aradım mı?
5. Eşleşen kullanıcı adlarını tek bir kişinin kanıtı olarak değil, bir ipucu olarak tanımladım mı?
6. Rozetin mevcut güvenliği, yazarlığı veya istihdamı kanıtladığını iddia etmekten kaçındım mı?

Kendi izinizi korumak

Commit’lerinizi imzalıyorsanız, doğrulanmış bir rozetin arkanızda bıraktığınız bir kayıt olduğunu unutmayın. Onu üreten anahtardan daha uzun süre dayanabilir. Bir imzalama anahtarını iptal etmeden veya değiştirmeden önce, eski commit’lerin nasıl okunmasını istediğinize karar verin ve hangi anahtarların ne zaman kullanıldığına dair kendi notlarınızı tutun. Genel profilleri yönetiyorsanız, zaman içinde kullandığınız kullanıcı adlarını gözden geçirin ve eski hesapların hâlâ size işaret edip etmediğini kontrol edin. TraceSeek gibi bir kullanıcı adı araması, bilinen genel kullanıcı adlarınızı 3.000+ platformda gözden geçirmenize yardımcı olabilir; ilk tarama ücretsizdir ve kayıt veya oturum açma gerektirmez, sonuçlar genellikle 20-30 saniye içinde döner. Çıktıyı kimlik doğrulaması olarak değil, gözden geçirilecek ipuçları listesi olarak ele alın. TraceSeek platform ayarlarını değiştirmez, eşleşme garantisi vermez ve hiç kimsenin kimliğini doğrulamaz. Kanıtı ve sınırları nasıl çerçevelediğimiz için metodolojimizi inceleyin.

Temel gerçekler

• GitHub, imzası başarıyla doğrulanan bir commit’i Verified olarak işaretler.
• Doğrulama kaydedildikten sonra, kayıt bir imzalama anahtarı iptal edilse veya süresi dolsa bile varlığını sürdürebilir.
• Doğrulanmış commit rozeti belirli bir commit için imza sonucudur, mevcut hesap kontrolünün veya kimliğin kanıtı değildir.
• Platformlar arasında eşleşen genel tanımlayıcılar ipuçlarıdır, hesapların aynı kişiye ait olduğunun kanıtı değildir.
• TraceSeek 3.000+ platformu kapsar ve kayıt veya oturum açma olmadan ücretsiz ilk tarama sunar.