DEV Community

Cover image for Maigret คืออะไร: OSINT Scanner ที่ไม่พัง
Thanawat Wongchai
Thanawat Wongchai

Posted on • Originally published at apidog.com

Maigret คืออะไร: OSINT Scanner ที่ไม่พัง

เครื่องมือ OSINT ส่วนใหญ่ล้าสมัยเร็ว เพราะเว็บไซต์เปลี่ยน URL, เปลี่ยน HTML, เพิ่ม captcha หรือเปลี่ยนนโยบาย rate limit อยู่ตลอดเวลา แต่ Maigret อยู่รอดมาหลายปี รองรับเว็บไซต์มากกว่า 3,000 แห่ง มีทั้งแพ็กเกจ Python, บอท Telegram และเว็บ UI จุดที่น่าสนใจสำหรับนักพัฒนาไม่ใช่แค่ “ค้นหาชื่อผู้ใช้ได้” แต่คือสถาปัตยกรรมแบบ signature-driven ที่ทำให้เครื่องมือยังใช้งานได้แม้เว็บไซต์เปลี่ยนแปลงบ่อย

ลองใช้ Apidog วันนี้

คู่มือนี้โฟกัสมุมวิศวกรรม: Maigret ทำงานอย่างไร, ใช้ได้อย่างถูกต้องในบริบทใด, ทำไมฐานข้อมูลลายเซ็นถึงสำคัญ, และคุณจะนำรูปแบบเดียวกันไปใช้กับการทดสอบ API ใน Apidog ได้อย่างไร

หากคุณต้องการภาพรวมเรื่อง API testing เพิ่มเติม อ่านบทความ การทดสอบ API โดยไม่ต้องใช้ Postman ในปี 2026 ซึ่งอธิบายแนวคิด pattern matching และ drift detection ในบริบท API

สรุปสั้นๆ

  • Maigret ค้นหาบัญชีสาธารณะจากชื่อผู้ใช้ โดยตรวจสอบเว็บไซต์มากกว่า 3,000 แห่ง
  • แกนหลักคือฐานข้อมูลลายเซ็นเว็บไซต์, การตรวจจับหลายสัญญาณ, การค้นหาแบบวนซ้ำ และการตรวจจับความคลาดเคลื่อน
  • การใช้งานที่เหมาะสม ได้แก่ OSINT เชิงข่าว, การกู้คืนบัญชีของตัวเอง, brand monitoring, missing person search ที่ได้รับอนุญาต และ Red Team ที่มีขอบเขตชัดเจน
  • การใช้กับบุคคลโดยไม่ได้รับความยินยอมอาจเข้าข่ายคุกคามหรือสะกดรอยตาม
  • รูปแบบเดียวกันนี้ใช้กับ API testing ได้โดยตรง: endpoint signature, response validation, regression fixtures และ scheduled drift checks
  • Apidog เหมาะสำหรับนำแนวคิด signature-based validation ไปใช้กับ API contracts

Maigret คืออะไร

Maigret เป็นเครื่องมือ Python แบบ MIT license ดูแลโดย soxoj คำอธิบายใน README คือ “รวบรวมข้อมูลเกี่ยวกับบุคคลโดยใช้ชื่อผู้ใช้จากเว็บไซต์กว่า 3,000 แห่ง”

การใช้งานพื้นฐาน:

pip install maigret
maigret username
Enter fullscreen mode Exit fullscreen mode

เครื่องมือจะนำ username ไปตรวจสอบกับเว็บไซต์ในฐานข้อมูล จากนั้นดึงข้อมูลโปรไฟล์สาธารณะที่พบและสร้างรายงาน

สิ่งที่ต้องเข้าใจให้ชัด:

  1. Maigret ใช้ข้อมูลสาธารณะเท่านั้น

    ไม่มีการ login, ไม่มี credential stuffing, ไม่มี API key ของบุคคลอื่น หากเว็บไซต์เปิดโปรไฟล์ให้ผู้ใช้ anonymous อ่านได้ Maigret ก็อ่านได้ หากไม่เปิด ก็จะรายงานว่าไม่พบหรือไม่สามารถยืนยันได้

  2. ใช้งานได้ในบริบทที่ถูกต้องตามกฎหมาย

    เช่น นักข่าวสืบสวน, ทีมต่อต้าน fraud, ทีม brand protection, อาสาสมัครค้นหาบุคคลที่หายไปภายใต้การประสานงานที่เหมาะสม และ Red Team ที่ได้รับอนุญาต

  3. อาจถูกใช้ผิดวัตถุประสงค์ได้

    การค้นหาข้อมูลบุคคลส่วนตัวโดยไม่ได้รับความยินยอมอาจละเมิดกฎหมายการคุกคามหรือการสะกดรอยตามในหลายประเทศ ตรวจสอบกฎหมายท้องถิ่นและใช้เฉพาะในขอบเขตที่ได้รับอนุญาต

บทความนี้จะพูดถึงสถาปัตยกรรมและ pattern การทดสอบ ไม่ใช่ workflow สำหรับติดตามบุคคล

แกนหลัก: ฐานข้อมูลลายเซ็นของเว็บไซต์

แนวคิดที่ทำให้ Maigret scale ได้คือ “ฐานข้อมูลลายเซ็น” เว็บไซต์แต่ละแห่งมี metadata ที่บอก scanner ว่า:

  • URL สำหรับค้นหาโปรไฟล์คืออะไร
  • หน้า “พบผู้ใช้” มีลักษณะอย่างไร
  • หน้า “ไม่พบผู้ใช้” มีลักษณะอย่างไร
  • ต้องดู string, regex หรือ header ใด
  • เว็บไซต์มี rate limit หรือ captcha หรือไม่
  • สามารถดึงข้อมูลสาธารณะอะไรจากหน้าโปรไฟล์ได้

ฐานข้อมูลนี้อยู่ในรูป JSON และถูก version control ใน repository เมื่อมีเว็บไซต์เปลี่ยนโครงสร้าง ผู้ดูแลหรือชุมชนสามารถแก้ signature แล้วให้ installation ต่างๆ อัปเดตตามได้

แนวคิดเดียวกันใช้กับ API testing ได้ทันที แทนที่จะเขียน test แบบ hard-coded สำหรับทุก endpoint ให้กำหนด “ลายเซ็นของ endpoint” เป็นข้อมูล เช่น:

{
  "endpoint": "GET /users/{id}",
  "expectedStatus": 200,
  "requiredFields": ["id", "email", "created_at"],
  "forbiddenFields": ["password", "token"],
  "headers": {
    "content-type": "application/json"
  }
}
Enter fullscreen mode Exit fullscreen mode

เมื่อ API เปลี่ยน schema หรือ behavior ชุดทดสอบควร fail พร้อมข้อมูล diff ที่อ่านได้ แนวคิดนี้สอดคล้องกับ การพัฒนา API แบบสัญญาเป็นอันดับแรก และ คู่มือการทดสอบเซิร์ฟเวอร์ MCP

Maigret ตรวจจับ “พบ” และ “ไม่พบ” อย่างไร

Scanner แบบง่ายมักทำแบบนี้:

GET https://example.com/user/<username>
if status == 200:
    found
else:
    not found
Enter fullscreen mode Exit fullscreen mode

วิธีนี้ใช้ไม่ได้กับเว็บไซต์ส่วนใหญ่ เพราะหลายเว็บตอบ 200 OK แม้ไม่มีผู้ใช้นั้นอยู่จริง บางเว็บตอบหน้า home, หน้า error ที่ cache ไว้ หรือหน้า captcha

Maigret จึงใช้หลายสัญญาณ เช่น:

  • urlMain และ url
  • presenseStrs หรือ string ที่ต้องมีเมื่อพบผู้ใช้
  • absenceStrs หรือ string ที่ยืนยันว่าไม่มีผู้ใช้
  • regex สำหรับดึง username หรือ field อื่น
  • custom headers เช่น user agent
  • tags สำหรับหมวดหมู่หรือประเทศ

แนวคิด logic โดยย่อ:

def classify_response(body, presence_strings, absence_strings):
    has_presence = all(s in body for s in presence_strings)
    has_absence = any(s in body for s in absence_strings)

    if has_presence and not has_absence:
        return "found"

    if has_absence:
        return "not_found"

    return "unknown"
Enter fullscreen mode Exit fullscreen mode

นี่คือหลักเดียวกับ API testing ที่ดี: อย่าตรวจแค่ status code ต้องตรวจ body และ header ด้วย

ตัวอย่าง assertion สำหรับ API:

pm.test("response is valid user profile", function () {
  pm.response.to.have.status(200)

  const json = pm.response.json()

  pm.expect(json).to.have.property("id")
  pm.expect(json).to.have.property("email")
  pm.expect(json).to.not.have.property("password")
  pm.expect(pm.response.headers.get("Content-Type")).to.include("application/json")
})
Enter fullscreen mode Exit fullscreen mode

ใน Apidog คุณสามารถรวมการตรวจ status code, body field และ header ใน test case เดียวได้ ซึ่งเป็นรูปแบบเดียวกับ presenseStrs + absenceStrs ของ Maigret

การค้นหาแบบวนซ้ำและการดึงข้อมูล

เมื่อ Maigret พบโปรไฟล์ มันไม่ได้หยุดแค่นั้น แต่จะพยายามดึงข้อมูลสาธารณะเพิ่มเติม เช่น:

  • username อื่น
  • ชื่อจริง
  • email ที่เปิดเผย
  • phone number ที่เปิดเผย
  • link ไปยัง social profile อื่น

จากนั้น identifier ใหม่จะถูกนำกลับเข้า pipeline เพื่อค้นหาเพิ่ม นี่คือ recursive discovery

ใน API testing คุณใช้แนวคิดนี้ได้เช่นกัน เช่น เมื่อ endpoint หนึ่งคืนค่า field ที่ไม่อยู่ในเอกสาร:

{
  "id": "usr_123",
  "email": "dev@example.com",
  "billing_profile_id": "bp_789"
}
Enter fullscreen mode Exit fullscreen mode

ถ้า billing_profile_id ไม่เคยถูก document ไว้ นั่นคือสัญญาณให้เพิ่ม test หรือสำรวจ endpoint ที่เกี่ยวข้อง:

GET /billing-profiles/bp_789
Enter fullscreen mode Exit fullscreen mode

แนวทางปฏิบัติ:

  1. เก็บ response fixture ที่ “ถูกต้อง”
  2. ตรวจ field ใหม่ที่ไม่อยู่ใน schema
  3. ตัดสินใจว่า field นั้นควรถูก document, ถูกลบ หรือถูกทดสอบเพิ่ม
  4. เพิ่ม endpoint ที่เกี่ยวข้องเข้า test suite

การจัดการ captcha และ rate limit

Maigret ตรวจจับ captcha และ rate limit จากรูปแบบ response แล้วถอยกลับอย่างเหมาะสม แทนที่จะพยายามเจาะผ่าน protection

กลยุทธ์ที่ระบุไว้ ได้แก่:

  • หมุนเวียน user agent
  • เคารพ retry header ของแต่ละเว็บไซต์
  • ใช้ mobile หรือ simplified domain หากเว็บไซต์รองรับ
  • ใช้ Tor หรือ I2P เฉพาะเมื่อเว็บไซต์อนุญาต

หากเว็บมี anti-automation หนัก Maigret จะรายงานว่าเจอ captcha และให้ผู้ใช้ตรวจสอบเอง

สำหรับ API client หรือ test runner คุณควรออกแบบแบบเดียวกัน:

import time
import requests

def get_with_backoff(url, max_retries=3):
    for attempt in range(max_retries):
        response = requests.get(url)

        if response.status_code != 429:
            return response

        retry_after = int(response.headers.get("Retry-After", "1"))
        time.sleep(retry_after)

    raise RuntimeError("Rate limit still active after retries")
Enter fullscreen mode Exit fullscreen mode

หลักสำคัญคือ test runner ควร “รับรู้และถอย” ไม่ใช่ยิง request ถี่จนโดน block

ปัญหา signature drift

ฐานข้อมูลกว่า 3,000 เว็บไซต์จะมีประโยชน์ก็ต่อเมื่ออัปเดตทัน เว็บไซต์อาจ:

  • redesign หน้า profile
  • เปลี่ยน URL pattern
  • เพิ่ม captcha
  • เปลี่ยนข้อความ error
  • ถูกซื้อกิจการและ rebrand

เมื่อ signature เก่า จะเกิด:

  • false negative: มีบัญชีจริงแต่ไม่พบ
  • false positive: รายงานว่าพบ ทั้งที่ไม่มีบัญชีจริง

Maigret จัดการ drift ด้วยหลายชั้น:

  • auto-update จาก GitHub repo กลางทุก 24 ชั่วโมง
  • community pull requests สำหรับแก้ signature
  • flag --update เพื่อบังคับอัปเดต
  • test suite ที่ตรวจ signature กับ username ที่รู้ว่ามีอยู่จริงก่อน publish

จุดที่น่านำไปใช้กับ API คือ “known-good fixture” ตัวอย่าง:

{
  "endpoint": "GET /users/usr_123",
  "fixture": {
    "id": "usr_123",
    "email": "dev@example.com",
    "status": "active"
  }
}
Enter fullscreen mode Exit fullscreen mode

จากนั้นตั้ง schedule ให้เรียก endpoint จริงและ compare:

expected.status == actual.status
expected.body.required_fields ⊆ actual.body.fields
actual.body.forbidden_fields == []
Enter fullscreen mode Exit fullscreen mode

Apidog รองรับ workflow แนวนี้: บันทึก response ที่ถูกต้อง, เรียกซ้ำตามรอบ, เปรียบเทียบผลลัพธ์ และแจ้งเตือนเมื่อ contract drift เกิดขึ้น ดูตัวอย่างการทำงานกับ vendor API ได้ใน คู่มือ DeepSeek V4 API

โหมดสรุปด้วย AI

Maigret มี flag:

maigret username --ai
Enter fullscreen mode Exit fullscreen mode

โหมดนี้ใช้ LLM ที่เข้ากันได้กับ OpenAI เพื่อสรุปผลลัพธ์ที่ได้จาก deterministic search ให้เป็นรายงานอ่านง่าย คุณต้องเตรียม API key เอง

จุดที่ออกแบบถูกต้องคือ LLM ไม่ได้ตัดสินว่า “พบ” หรือ “ไม่พบ” การตัดสินนั้นมาจาก rule-based engine ส่วน LLM ทำหน้าที่ post-processing เท่านั้น

รูปแบบที่เหมาะกับ API testing คือ:

  1. deterministic assertions ตัดสิน pass/fail
  2. structured test report เก็บผลจริง
  3. LLM สรุป report เป็นข้อความสำหรับทีม

ตัวอย่าง flow:

Apidog test run
 -> deterministic assertions
 -> JSON report
 -> LLM summary
 -> Slack / issue tracker
Enter fullscreen mode Exit fullscreen mode

แนวคิดนี้สอดคล้องกับบทความ การใช้งานคอมพิวเตอร์เทียบกับ API ที่มีโครงสร้าง: ให้ layer ที่มีโครงสร้างตัดสินก่อน แล้วค่อยใช้ AI ช่วยสรุป

กรณีการใช้งานที่ชอบด้วยกฎหมาย

ตัวอย่างที่เหมาะสม:

  • กู้คืนบัญชีของตัวเอง

    ค้นหาบัญชีเก่าที่ผูกกับ username ที่คุณเคยใช้ เพื่อปิดบัญชีหรือปรับ privacy

  • ตรวจสอบการละเมิดแบรนด์

    บริษัทใช้ชื่อแบรนด์หรือชื่อผลิตภัณฑ์เพื่อตรวจบัญชีแอบอ้าง

  • ค้นหาบุคคลที่หายไปภายใต้การประสานงาน

    ใช้เมื่อได้รับความยินยอมจากครอบครัวและประสานกับหน่วยงานที่เกี่ยวข้อง

  • Red Team ที่ได้รับอนุญาต

    ใช้ภายใต้สัญญา pentest เพื่อ map public attack surface ขององค์กร

  • วารสารศาสตร์เชิงสืบสวน

    ใช้ภายใต้กระบวนการตรวจสอบของกองบรรณาธิการและฝ่ายกฎหมาย

สิ่งที่ไม่ควรทำ: ค้นหาคนแปลกหน้าด้วยความอยากรู้, สอดแนมอดีตคู่รัก, หรือสร้าง dataset ของบุคคลที่ไม่ได้ให้ความยินยอม

Pattern จาก Maigret ที่นำไปใช้กับ API testing ได้

1. ใช้ฐานข้อมูลลายเซ็นแทน test ที่ hard-code กระจัดกระจาย

เก็บ expectation เป็นข้อมูล:

- endpoint: GET /users/{id}
  status: 200
  required:
    - id
    - email
    - created_at
  forbidden:
    - password
    - access_token
Enter fullscreen mode Exit fullscreen mode

ข้อดีคือเพิ่มหรือแก้ endpoint ได้โดยไม่ต้อง rewrite test runner

2. ตรวจหลายสัญญาณพร้อมกัน

อย่าตรวจแค่ 200 OK ให้ตรวจ:

  • status code
  • required fields
  • forbidden fields
  • content type
  • error envelope
  • response time threshold หากจำเป็น

3. อัปเดต signature จากแหล่งกลาง

ถ้าทีมมีหลาย service ให้เก็บ API contract ในที่เดียวและ sync ไปยัง project ที่เกี่ยวข้อง แนวทางนี้เหมือน signature database ของ Maigret และสอดคล้องกับ workflow ใน การทดสอบ API โดยไม่ต้องใช้ Postman

4. ตั้ง scheduled drift detection

ตัวอย่าง schedule:

ทุก 1 ชั่วโมง:
  run smoke contract tests

ทุกวัน:
  run full regression suite

ทุก release:
  compare schema against previous baseline
Enter fullscreen mode Exit fullscreen mode

เมื่อ field หาย, type เปลี่ยน หรือ error envelope เปลี่ยน ต้องแจ้งเตือนก่อนกระทบผู้ใช้

5. ใช้ LLM เป็น postprocessor เท่านั้น

ให้ test rule ตัดสินผล:

PASS / FAIL / UNKNOWN
Enter fullscreen mode Exit fullscreen mode

แล้วให้ LLM ช่วยแปลง report เป็น summary เช่น:

3 endpoints failed after the latest deployment.
Most failures are missing `billing_profile_id` in user responses.
Enter fullscreen mode Exit fullscreen mode

อย่าให้ LLM เป็นตัวตัดสิน contract correctness

ข้อผิดพลาดที่พบบ่อยเมื่อใช้ Maigret

  • ไม่ใช้ -a แล้วคิดว่าสแกนครบทั้งหมด ค่าเริ่มต้นสแกนเฉพาะเว็บไซต์ยอดนิยมประมาณ 500 แห่ง หากต้องการครบมากกว่า 3,000 แห่งให้ใช้: 
  maigret username -a
Enter fullscreen mode Exit fullscreen mode

  • ไม่ใช้ tags

    ใช้ --tags เพื่อจำกัดตามประเทศหรือหมวดหมู่ เช่นกรณีต้องการค้นหา service เฉพาะภูมิภาค

  • ไม่อัปเดตฐานข้อมูลลายเซ็น

    ใช้ auto-update หรือสั่งเอง:

  maigret --update
Enter fullscreen mode Exit fullscreen mode

  • ตีความ Tor block ผิด

    บางเว็บ block Tor exit node อยู่แล้ว อย่านำผลนั้นไปตีความว่าเกี่ยวกับ username

  • เชื่อข้อมูลที่ดึงมาโดยไม่ตรวจสอบ

    หน้าโปรไฟล์สามารถปลอมได้ ข้อมูลจาก Maigret ควรเป็น clue ไม่ใช่หลักฐานสุดท้าย

กรณีการใช้งานจริง

บริษัทที่ปรึกษาด้านความปลอดภัยใช้ Maigret เป็นขั้นตอนแรกในการกำหนดขอบเขต Red Team เพื่อให้ลูกค้าเห็น public attack surface ก่อนเริ่มงานจริง

นักสืบสวน fraud ใช้ --ai เพื่อสรุปผลการสแกนหลายพันเว็บไซต์ให้เป็นรายงานสั้นสำหรับลูกค้าที่ไม่ใช่สายเทคนิค โดยให้ deterministic search เป็นแหล่งข้อมูล และให้ LLM ทำหน้าที่สรุปเท่านั้น

ทีมวิศวกรรมสามารถใช้สถาปัตยกรรมเดียวกันกับ API testing: signature database, drift detection และ scheduled re-check สำหรับ microservices ภายใน โดยสร้าง workflow ใน Apidog

บทสรุป

Maigret เป็นตัวอย่างที่ดีของเครื่องมือที่ scale ไปยังกฎการตรวจจับจำนวนมากโดยไม่พังทุกครั้งที่ target เปลี่ยน สิ่งที่นักพัฒนาควรศึกษาไม่ใช่แค่ OSINT แต่คือ pattern เหล่านี้:

  • signature database ที่ version control ได้
  • multi-signal validation
  • auto-update ของ rule set
  • regression test กับ known-good fixture
  • drift detection
  • LLM post-processing ที่ไม่แทนที่ deterministic rules

ข้อคิดสำคัญ:

  • Maigret ตรวจเว็บไซต์มากกว่า 3,000 แห่งด้วย signature database ที่อัปเดตได้
  • presence strings และ absence strings เชื่อถือได้กว่าการดู status code อย่างเดียว
  • signature drift เป็นปัญหาเดียวกับ API contract drift
  • LLM ควรใช้เพื่อสรุป ไม่ใช่ตัดสิน pass/fail
  • รูปแบบเดียวกันนี้นำไปใช้กับ API testing ใน Apidog ได้โดยตรง

ขั้นตอนต่อไป: อ่านรูปแบบฐานข้อมูลเว็บไซต์ของ Maigret จากนั้นเปิด Apidog แล้วเลือก endpoint หนึ่งในโปรเจกต์ของคุณมาทำ signature-based validation: กำหนด expected status, required fields, forbidden fields และ fixture สำหรับ drift detection ครั้งแรกที่ vendor เปลี่ยน field ตอนกลางคืน ชุดทดสอบของคุณจะเตือนก่อนผู้ใช้เจอปัญหา

คำถามที่พบบ่อย

Maigret ใช้งานถูกกฎหมายหรือไม่?

ขึ้นอยู่กับเขตอำนาจศาลและเป้าหมาย การใช้กับบัญชีของตัวเอง, บริษัทที่ให้อนุญาตเป็นลายลักษณ์อักษร, หรือการทำงานข่าวภายใต้กระบวนการที่เหมาะสมโดยทั่วไปถือว่าใช้ได้ การใช้กับบุคคลที่ไม่ได้ให้ความยินยอมอาจละเมิดกฎหมายการคุกคามหรือการสะกดรอยตาม ตรวจสอบกฎหมายท้องถิ่นก่อนใช้งาน

Maigret ทำงานได้โดยไม่มี Python หรือไม่?

แพ็กเกจหลักต้องใช้ Python 3.10 ขึ้นไป ผู้เขียนยังดูแล บอท Telegram และ Cloud Shell สำหรับผู้ใช้ที่ไม่ต้องการติดตั้งในเครื่อง

ตัวเลข 3,000 เว็บไซต์แม่นยำแค่ไหน?

repository มีรายการมากกว่า 3,000 เว็บไซต์ แต่ไม่ใช่ทุกเว็บไซต์จะใช้งานได้ตลอดเวลา เว็บไซต์เปลี่ยนแปลงได้เสมอ การอัปเดตลายเซ็นและการกรองด้วย tags ช่วยให้ผลลัพธ์ตรงขอบเขตมากขึ้น

โหมด AI เพิ่มอะไรเข้ามา?

flag --ai ใช้ LLM ที่เข้ากันได้กับ OpenAI เพื่อสรุปผลลัพธ์ให้เป็นรายงานอ่านง่าย ไม่ได้เปลี่ยน logic การค้นหา คุณต้องเตรียม API key เอง

ใช้ Maigret ใน CI ได้ไหม?

สำหรับงาน OSINT จริงไม่เหมาะ เพราะต้องมีบริบทและการตรวจสอบโดยมนุษย์ แต่ pattern ของ Maigret เช่น signature database, drift detection และ scheduled re-check เหมาะมากสำหรับ CI pipeline ของ API testing ซึ่ง Apidog รองรับ workflow ลักษณะนี้

ต่างจาก Sherlock อย่างไร?

Sherlock เป็นเครื่องมือเก่าที่เรียบง่ายกว่า Maigret เพิ่มความสามารถด้านการดึงข้อมูล, recursive search, captcha handling, AI summary และฐานข้อมูลเว็บไซต์ที่ละเอียดกว่า ทั้งสองเป็น MIT license และควรศึกษาในเชิงสถาปัตยกรรม

จะรายงาน signature ที่ล้าสมัยได้ที่ไหน?

README ของ Maigret ชี้ไปที่ GitHub issues และ pull requests ใน repository การมีส่วนร่วมของชุมชนเป็นส่วนสำคัญที่ทำให้ฐานข้อมูลลายเซ็นยังทันสมัยอยู่เสมอ

Top comments (0)