Java เตรียมอ่านไฟล์ PEM ง่ายขึ้น แต่ทีมงานยังต้องวางแผนอัปเกรด

Java เตรียมทำเครื่องมือแปลงไฟล์คีย์และใบรับรองเป็นฟีเจอร์ถาวรใน JDK 28 แปลว่าโปรแกรมจะมีทางอ่านเขียนไฟล์แบบนี้โดยตรงตามข้อเสนอ JEP 542 ครับ Inside.java ใน URL วันที่ 6 ต.ค. ยืนยันว่าข้อเสนอนี้มีเป้าหมายเข้ารุ่นดังกล่าว แต่ยังอย่าสับสนกับประกาศว่าโปรแกรมของบริษัทพร้อมย้ายวันนี้

เรื่องนี้เกี่ยวกับไฟล์ที่ทีมพัฒนาต้องรับส่งตอนเชื่อมระบบ ไม่ได้เป็นปุ่มใหม่ให้คนใช้แอปกด เอกสารระบุว่า Java มีเครื่องมือด้านคีย์และใบรับรองอยู่แล้ว แต่ยังขาดวิธีแปลงข้อความ PEM ที่ใช้ง่ายและครอบคลุมงานเหล่านี้ ตามคำอธิบายของ OpenJDK สำหรับคนดูแลงานรับเงินหรือเอกสารออนไลน์ ประเด็นจึงอยู่ที่งานเบื้องหลังซึ่งทีมต้องดูแลให้ถูกต้อง

สรุป 30 วินาที: เกิดอะไรขึ้น

PEM คือรูปแบบข้อความสำหรับส่งหรือเก็บข้อมูลด้านการเข้ารหัส ชื่อเต็มคือ Privacy-Enhanced Mail ซึ่งเดิมออกแบบไว้ใช้ทางอีเมล ก่อนถูกนำไปใช้งานอื่น JEP 542 อธิบายว่าหน่วยงานออกใบรับรองส่งชุดใบรับรองในรูปแบบนี้ด้วย ไฟล์จึงดูเหมือนข้อความธรรมดา แต่สิ่งที่บรรจุอยู่มีชนิดและโครงสร้างเฉพาะ

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

เส้นทางก่อนหน้านี้เริ่มทดลองใน JDK 25 แปลว่า API เคยเปิดให้ใช้แบบยังอาจเปลี่ยนแปลงได้ ประวัติใน JEP 542 ระบุว่ารอบต่อมาอยู่ใน JDK 26 ซึ่งมีการปรับเล็กน้อย ส่วนรอบทดลองล่าสุดอยู่ใน JDK 27 ตาม JEP 538 และรอบถาวรเสนอให้คง API จากรอบนั้นโดยไม่เปลี่ยนเพิ่มเติม

คำว่า final หรือถาวรจึงหมายถึงสถานะของ API ครับ ส่วน JDK คือชุดเครื่องมือสำหรับพัฒนาและใช้งานโปรแกรม Java ซึ่งมีวงจรออกรุ่นของตัวเอง หน้าโครงการ JDK 28 ระบุว่ามีชุดทดลองก่อนออกรุ่นจริงให้ดาวน์โหลด แต่ข้อความที่เราได้รับไม่มีกำหนดวันเปิดใช้ทั่วไป ต้องแยกข่าวฟีเจอร์กับปฏิทินอัปเกรดออกจากกัน

ทำไมเรื่องนี้เกี่ยวกับคุณ

ถ้าคุณเป็นเจ้าของร้านหรือดูแลงานสำนักงาน ลองถามทีมพัฒนาว่ามีจุดไหนรับไฟล์ .pem จากคู่ค้าบ้าง เช่น งานเชื่อมธนาคาร เอกสารภาษีอิเล็กทรอนิกส์ หรือผู้ให้บริการรับชำระเงิน นี่เป็นโจทย์ให้สำรวจระบบของคุณ ไม่ใช่คำยืนยันว่าผู้ให้บริการไทยรายใดใช้รูปแบบใด เพราะแหล่งข่าวชุดนี้ไม่ได้ระบุชื่อหรือการรองรับของบริการไทย

เหตุที่ควรถามคือ OpenJDK อธิบายว่าคีย์และใบรับรองถูกใช้กับการลงลายมือชื่อ การตรวจลายมือชื่อ และการตรวจการเชื่อมต่อที่ป้องกันด้วย TLS หรือมาตรฐานป้องกันข้อมูลระหว่างเชื่อมต่อ งานอ่านไฟล์จึงเป็นส่วนต้นทางก่อนนำข้อมูลไปใช้ในขั้นตอนเหล่านี้ แต่การอ่านสำเร็จเพียงอย่างเดียวไม่ใช่หลักฐานว่ากระบวนการธุรกิจทั้งหมดถูกต้องแล้ว

สำหรับฝ่ายดูแลระบบที่ต้องเปลี่ยนใบรับรอง คำถามที่ทำตามได้คือไฟล์ใหม่ผ่านเส้นทางอ่านเดียวกับไฟล์เดิมหรือไม่ เอกสารบอกว่าแอปส่งรับข้อมูลเหล่านี้ผ่านเครือข่าย หน้าจอ หรืออุปกรณ์เก็บข้อมูลได้ ตาม JEP 542 จึงควรตรวจทั้งจุดนำเข้าและจุดส่งออก ก่อนเปลี่ยนวิธีแปลงไฟล์ในระบบที่คนอื่นพึ่งพา

แล้วคนที่ไม่ได้เขียน Java ต้องติดตั้งอะไรเพิ่มไหม? ข่าวนี้ไม่ได้ระบุขั้นตอนสำหรับผู้ใช้แอปทั่วไป สิ่งที่ทำได้คือส่งประเด็นให้ผู้รับผิดชอบระบบตรวจ และขอแผนทดสอบที่ชัดเจน โดยยังไม่จำเป็นต้องเปิดไฟล์คีย์มาแก้เองเพื่อให้ทันข่าว

ทำงานยังไง

ข้อความ PEM มีส่วนหัวและส่วนท้ายที่ระบุชนิดข้อมูล เช่นคำว่า BEGIN และ END โดยข้อความตรงกลางใช้ Base64 ซึ่งเป็นวิธีเขียนข้อมูลไบนารีให้อยู่ในรูปตัวอักษร JEP 542 ยกตัวอย่างคีย์สาธารณะ และอธิบายว่าต้องอ่านข้อมูลข้างในต่อจึงจะทราบรายละเอียด คำว่า Base64 ไม่ได้หมายถึงการเข้ารหัสด้วยรหัสผ่าน

สำหรับไฟล์ใบรับรอง ป้ายอย่าง -----BEGIN CERTIFICATE----- ทำหน้าที่บอกประเภท ไม่ได้บอกว่าใบรับรองนั้นควรเชื่อถือทันที เอกสารแยกการแปลงข้อความออกจากงานด้านการเข้ารหัสที่โปรแกรมนำข้อมูลไปทำต่อ ตามขอบเขตของ JEP 542 ดังนั้นทีมยังต้องออกแบบการตรวจข้อมูลให้ตรงกับงานของระบบตัวเอง

เปรียบกับ เครื่องแปลงซองจดหมายมาตรฐาน ในสำนักงานไทยครับ คนส่งใส่ข้อมูลในซองที่มีป้ายบอกประเภท คนรับไม่ต้องเขียนวิธีแกะซองใหม่ทุกครั้ง เครื่องอ่านป้ายแล้วนำข้อมูลไปอยู่ในรูปที่แผนกปลายทางใช้ได้ แต่ข้อความในจดหมายถูกต้องหรือไม่ยังต้องตรวจต่อ อุปมานี้อธิบายหน้าที่แปลงรูปแบบตาม ข้อเสนอ OpenJDK

ตัวส่งออกชื่อ PEMEncoder รับข้อมูลที่รองรับแล้วทำเป็นข้อความ PEM ส่วนตัวรับเข้าชื่อ PEMDecoder อ่านข้อความกลับเป็นข้อมูล Java JEP 542 ระบุว่าทั้งคู่ใช้ซ้ำได้และไม่เก็บข้อมูลจากรายการก่อนหน้าไว้ในตัวแปลง แปลว่าทีมไม่ต้องสร้างวิธีแปลงเฉพาะกิจใหม่สำหรับข้อมูลทุกชิ้น

อีกส่วนคือ BinaryEncodable ซึ่งเป็นข้อกำหนดร่วมให้ข้อมูลที่แปลงเป็นไบนารีได้ถูกประมวลผลผ่านทางเดียวกัน และ PEM เป็นคลาสหรือแม่แบบข้อมูลสำหรับชนิดที่ Java ยังไม่มีตัวแทนโดยตรง ตาม JEP 542 ตัวหลังเก็บข้อความได้กว้างกว่า แต่เอกสารระบุชัดว่าการส่งออกจากมันไม่ได้ตรวจความถูกต้องของเนื้อหาภายใน

จุดหักมุม: ฟีเจอร์ถาวร แต่แผนอัปเกรดยังไม่ถาวรตาม

แต่ข่าวนี้ไม่ได้ทำให้เครื่องที่ใช้ Java รุ่นเก่าได้รับ API ใหม่ทันทีครับ JEP 542 ระบุรุ่นเป้าหมายของฟีเจอร์ ขณะที่ หน้าโครงการ ยังอธิบายการพัฒนาและชุดทดลองก่อนออกจริง จึงไม่ควรใช้คำว่า Completed บนหน้าข้อเสนอแทนคำว่าเปิดใช้ทั่วไปแล้ว

อีกเรื่องคือ LTS หรือการสนับสนุนระยะยาว แหล่งที่ให้มาไม่ระบุว่ารุ่นเป้าหมายนี้เป็น LTS หรือไม่ และไม่ให้กำหนดรุ่น LTS ถัดไป ข้อมูลบนหน้าโครงการ จึงยังไม่พอให้ฟันธงเรื่องระยะเวลาสนับสนุน ต้องตรวจแผนของผู้จำหน่าย Java ที่องค์กรใช้อยู่

ถ้าทีมวางแผนอยู่กับ JDK 21 ให้ใช้เส้นทางอ่านไฟล์เดิมไปก่อน ส่วนทีมที่อยู่กับ JDK 25 ต้องจำว่าประวัติของ API ในรุ่นนั้นยังเป็นการทดลอง ตาม JEP 542 อย่าถอดไลบรารีหรือชุดโค้ดเสริมเพราะอ่านคำว่า final แล้วคิดว่ารุ่นปัจจุบันของตัวเองเปลี่ยนตาม

เรื่องเงิน / ผลกระทบ

ผลต่อเงินในข่าวนี้ยังวัดเป็นบาทไม่ได้ครับ JEP 542 ให้เหตุผลว่าการอ่านคีย์ PEM ต้องแยกข้อความ เลือกตัวสร้างคีย์ และระบุวิธีเข้ารหัสให้ถูกต้อง แต่ไม่ได้ให้ตัวเลขเวลาที่ประหยัดหรือผลตอบแทนการลงทุน จึงควรคุยเรื่องงานดูแลที่อาจลดลง ก่อนคุยเรื่องงบที่ประหยัดแน่นอน

รายละเอียดสำคัญคือ Java ไม่ได้อ่าน PEM ไม่เป็นทุกกรณี เอกสารระบุว่า CertificateFactory ซึ่งเป็นตัวสร้างข้อมูลใบรับรอง รองรับการอ่านใบรับรองและรายการเพิกถอนจาก PEM อยู่แล้ว ในหัวข้อ Alternatives ของ JEP 542 ช่องว่างที่ข้อเสนอแก้คือความสะดวกและความสอดคล้องของการแปลงข้อมูลหลายประเภท โดยเฉพาะเมื่อเกี่ยวกับคีย์

รายการเพิกถอนใบรับรอง หรือ CRL คือข้อมูลที่ระบุใบรับรองซึ่งถูกถอนการรับรองออกจากการใช้งาน ข้อเสนอรองรับการแปลงข้อมูลประเภทนี้ร่วมกับใบรับรองและคีย์ ตาม JEP 542 สำหรับทีมงาน ประเด็นคือทำบัญชีให้ครบว่าโปรแกรมอ่านอะไรอยู่ ไม่ใช่เห็นนามสกุลเหมือนกันแล้วสรุปว่าทุกไฟล์ทดแทนกันได้

คีย์ส่วนตัวเป็นข้อมูลฝั่งที่ต้องเก็บเป็นความลับ ส่วนคีย์สาธารณะเป็นข้อมูลอีกฝั่งที่ใช้กับงานตรวจสอบ JEP 542 รองรับทั้งคีย์และคู่คีย์ พร้อมทางเข้ารหัสคีย์ส่วนตัวด้วยรหัสผ่าน ข้อแนะนำสำหรับทีมคือห้ามนำคีย์ส่วนตัวจริงไปวางในเว็บแปลงไฟล์ออนไลน์เพื่อทดลอง ควรใช้ข้อมูลทดสอบในสภาพแวดล้อมที่องค์กรควบคุม

รายละเอียดสำหรับทีมเทคนิค

การเข้ารหัสคีย์ส่วนตัวใช้ withEncryption และการถอดรหัสใช้ withDecryption ตาม JEP 542 ส่วน EncryptedPrivateKeyInfo เป็นตัวแทนคีย์ส่วนตัวที่เข้ารหัสแล้ว ซึ่งมีทางดึงคีย์หรือคู่คีย์กลับมาได้ แต่กรณีดึงคู่คีย์ต้องมีคีย์สาธารณะอยู่ในข้อมูลด้วย จึงควรทดสอบไฟล์ที่มีจริงแทนการคาดจากชื่อไฟล์

ตัวรับเข้ารองรับทั้งข้อความในโปรแกรมและสายข้อมูลที่อ่านเข้ามา และเลือกตัวให้บริการด้านการเข้ารหัสผ่าน withFactoriesOf ได้ ตาม JEP 542 ตัวให้บริการในที่นี้คือส่วนที่สร้างหรือประมวลผลข้อมูลคีย์และใบรับรอง หากตัวที่เลือกสร้างข้อมูลชนิดที่ต้องการไม่ได้ เอกสารระบุว่าจะเกิดข้อผิดพลาด จึงควรใส่กรณีนี้ในรายการทดสอบด้วย

ข้อเสนอแยกความผิดพลาดของข้อความที่อ่านไม่ได้ออกจากความผิดพลาดตอนถอดรหัส JEP 542 ระบุ IllegalArgumentException สำหรับข้อมูล PEM ที่แยกอ่านไม่ได้ และ CryptoException สำหรับความล้มเหลวด้านการเข้ารหัส ข้อแนะนำคือให้ข้อความแจ้งปัญหาบอกขั้นตอนที่ล้มเหลว โดยไม่แสดงเนื้อหาคีย์จริงให้คนที่ไม่เกี่ยวข้องเห็น

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

สถานะมีรายละเอียดต่างกัน แต่ยังไม่มีหลักฐานว่าใครคัดค้านการทำเป็นถาวร Inside.java บอกว่าฟีเจอร์มีเป้าหมายเข้ารุ่นใหม่ ส่วน JEP 542 แสดงสถานะ Completed และรุ่นที่เกี่ยวข้อง ขณะที่รายการ Features ใน หน้าโครงการที่อัปเดต 7 ต.ค. ที่ได้รับไม่แสดงข้อเสนอนี้ เราจึงบอกได้ว่าแหล่งสรุปสถานะไม่ครบเหมือนกัน แต่ยังอธิบายสาเหตุไม่ได้

วันที่ของ Inside.java มีจุดไม่ตรงกัน URL ของ โพสต์ targeted ระบุวันที่ 6 ต.ค. แต่ข้อมูลกำกับในไฟล์แหล่งข่าวระบุวันที่ 1 ม.ค. และเนื้อหาสั้นที่ได้รับไม่แสดงวันที่เผยแพร่ให้ตรวจซ้ำ บทความนี้จึงเรียกว่าโพสต์ใน URL วันที่ดังกล่าว ไม่เลือกข้อมูลกำกับมาใช้เป็นวันประกาศโดยเงียบ ๆ

เสียงสนับสนุนมาจาก OpenJDK และทีม Java ที่ Oracle JEP 542 ตั้งเป้าให้แปลงข้อมูลได้ง่ายและรองรับมาตรฐาน ส่วน Inside.java ประกาศทิศทางรุ่นเป้าหมาย แต่ Inside.java ระบุเองว่าเป็นข่าวและมุมมองจากสมาชิกทีม Java ที่ Oracle จึงไม่ใช่สื่ออิสระที่มายืนยันผลใช้งานอีกชั้นหนึ่ง

เสียงค้านที่มีจริงในเอกสารเป็นข้อโต้แย้งต่อวิธีออกแบบทางเลือก OpenJDK ระบุว่าการยัดงานเพิ่มใน KeyFactory หรือตัวสร้างคีย์ทำให้จัดการหลายรูปแบบยาก และผู้ดูแลตัวให้บริการอาจไม่ต้องการรับภาระอ่านเขียน PEM เพิ่ม ตามหัวข้อ Alternatives นี่เป็นเหตุผลที่ผู้เขียนข้อเสนอยกมาประเมินแบบอื่น ไม่ใช่คำคัดค้านที่ผู้ดูแลรายใดออกมาประกาศ เราไม่มีแหล่งเสียงค้านอิสระในชุดนี้ครับ

คำว่าไม่เปลี่ยนเพิ่มเติมต้องเทียบกับรอบทดลองล่าสุด JEP 538 เคยเปลี่ยน PEM จาก record ซึ่งเป็นรูปแบบคลาสสำหรับเก็บข้อมูล มาเป็นคลาสทั่วไป และเปลี่ยนชื่อเป็น BinaryEncodable ส่วน JEP 542 เสนอคง API จากรอบนั้น แปลว่าโค้ดที่เขียนตามรอบทดลองแรกยังควรตรวจชื่อและชนิดข้อมูล ไม่ใช่ถือว่าเหมือนกันมาตลอด

วันออกจริงและผลกับบริการไทยยังไม่มีคำตอบ หน้าโครงการ ที่ได้รับไม่ให้วัน GA หรือวันเปิดใช้ทั่วไป และแหล่งทั้งหมดไม่บอกว่าบริการธนาคาร ภาษี หรือรับชำระเงินไทยใดผ่านการทดสอบ API นี้แล้ว เมื่อยังไม่มีผลทดลองกับไฟล์ขององค์กร จะรับรองว่าเปลี่ยนแล้วใช้ได้ทุกจุดจากอะไร? คำตอบต้องมาจากการทดสอบของทีม ไม่ใช่ชื่อฟีเจอร์

แล้วเราควรทำอะไร

คนทั่วไปและเจ้าของกิจการ

1. ส่งข่าวให้ผู้ดูแลระบบ พร้อมถามว่ามีงานรับส่งคีย์หรือใบรับรอง PEM อยู่ตรงไหน ขอให้ตอบเป็นรายการระบบที่เกี่ยวข้อง โดยไม่แนบไฟล์ลับมากับคำถาม
2. ขอให้ทีมแยกแผนทดลองออกจากวันย้ายระบบจริง และแจ้งว่าต้องหยุดบริการหรือเปลี่ยนขั้นตอนงานหรือไม่ อย่าสั่งอัปเกรดทั้งระบบเพียงเพราะ API เปลี่ยนสถานะ
3. ถ้ามีคนขอให้นำคีย์ส่วนตัวไปวางในเว็บแปลงไฟล์ ให้หยุดและติดต่อผู้รับผิดชอบก่อน ข้อแนะนำนี้เป็นเรื่องการจัดการข้อมูลลับ ไม่ใช่ข้อกล่าวหาว่าเว็บใดในข่าวมีปัญหา

ทีม IT และฝ่ายดูแลใบรับรอง

1. ตรวจรุ่น Java และผู้จำหน่ายที่ใช้จริง แล้วดูแผนสนับสนุนของรายนั้น แหล่งข่าวชุดนี้ไม่ได้ให้ข้อมูล LTS จึงต้องตรวจเพิ่มก่อนผูกกำหนดอัปเกรดกับงบหรือสัญญา
2. เตรียมไฟล์ทดสอบแยกจากข้อมูลจริง ทั้งใบรับรอง คีย์สาธารณะ และคีย์ส่วนตัวที่เข้ารหัสไว้ ขอบเขตเหล่านี้อยู่ใน JEP 542 ให้ตรวจผลกับงานที่ระบบต้องทำต่อ ไม่หยุดเพียงแค่โหลดไฟล์ได้
3. รักษาวิธีอ่านไฟล์เดิมไว้จนกว่ารุ่นที่เลือกและผลทดสอบจะผ่านเกณฑ์องค์กร จดผู้รับผิดชอบการย้อนกลับด้วย เพื่อไม่ให้การเปลี่ยนเครื่องมือกลายเป็นงานแก้ปัญหาที่ไม่มีเจ้าของ

นักพัฒนา Java

1. เริ่มจากชุด Early Access หรือรุ่นทดลองก่อนออกจริงที่ หน้าโครงการ JDK 28 ระบุว่ามีให้ดาวน์โหลด ตรวจว่า build ที่เลือกมี API นี้ก่อนเริ่ม บทความนี้อธิบายเอกสารและยังไม่ได้ทดลองรันจริง
2. เทียบโค้ดเดิมกับชนิดข้อมูลและชื่อเมธอดใน JEP 542 โดยเฉพาะงานที่เคยใช้รอบทดลองเก่า ทดสอบข้อมูลอ่านไม่ได้ รหัสผ่านผิด และข้อมูลชนิดที่ไม่มีตัวแทน Java โดยตรงด้วย
3. หากโครงการใช้ BouncyCastle หรือไลบรารีเสริมอื่นอยู่ ให้เก็บไว้จนกว่าจะย้ายและตรวจขอบเขตครบ แหล่งข่าวไม่ได้ระบุว่า API นี้ทดแทนความสามารถทั้งหมดของไลบรารีใด การถอดจึงควรตัดสินจากงานที่ใช้อยู่จริง
4. ทดสอบการส่งออกแล้วอ่านกลับ รวมถึงแลกไฟล์กับเครื่องมือภายนอกที่ระบบใช้อยู่ แผนทดสอบใน JEP 542 ระบุทั้งการอ่านไฟล์จากแอปอื่นและทิศทางกลับกัน ข้อแนะนำคือใช้เกณฑ์เดียวกันกับไฟล์ทดสอบของทีม

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

ผมมองว่า…

ผมมองว่าเรื่องนี้ ไม่ใช่การทำให้ทุกระบบปลอดภัยขึ้นทันที แต่คือการลดงานแปลงรูปแบบที่ทีมต้องดูแลเอง คุณค่าของมันอยู่ที่การมีทางอ่านเขียนข้อมูลซึ่งอธิบายชัดและทดสอบร่วมกันได้ แต่อย่าเอาความสะดวกของ API ไปแทนการตรวจใบรับรอง การเก็บคีย์ และการดูแลขั้นตอนธุรกิจ

ผมมองว่าทีมเล็กควรเริ่มจากเลือกจุดทดลองที่มีขอบเขตชัด เช่นส่วนรับเข้าไฟล์ทดสอบของระบบเดียวก่อน แล้วค่อยประเมินว่าลดโค้ดดูแลได้จริงหรือไม่ การรอแผนสนับสนุนให้ชัดไม่ได้แปลว่าตกข่าว และการทดลองเร็วก็ไม่จำเป็นต้องรีบเปลี่ยนระบบรับเงินจริง

ปิดท้าย: สิ่งที่ต้องจับตา

ข่าวนี้ทำให้คำถามของทีมเปลี่ยนจากวิธีแกะไฟล์ ไปเป็นวิธีวางแผนย้ายอย่างตรวจสอบได้ สิ่งแรกที่ต้องติดตามคือสถานะและกำหนดเปิดใช้ทั่วไปจาก หน้าโครงการ เพราะข้อมูลที่ได้รับยังไม่มีวันดังกล่าว สิ่งถัดมาคือผลทดสอบกับไฟล์และตัวให้บริการด้านการเข้ารหัสที่องค์กรใช้งานจริง

สำหรับระบบของคุณ จุดไหนที่ทีมยังต้องเขียนวิธีอ่านไฟล์ PEM เอง และจะเลือกจุดนั้นเป็นงานทดลองแรกได้หรือไม่?

Recap

• เกิดอะไรขึ้น: OpenJDK เสนอทำ PEM API เป็นถาวร โดยคง API จากรอบทดลองล่าสุด
• รุ่นที่ต้องจำ: JDK 28 แปลว่าเป้าหมายอยู่ในรุ่นใหม่ ไม่ใช่การเปลี่ยนความสามารถของเครื่องรุ่นเก่าโดยอัตโนมัติ
• ข้อมูลต่างกัน: Inside.java ระบุ targeted แต่หน้าโครงการที่ได้รับไม่แสดงข้อเสนอนี้ในรายการ Features และวันที่กำกับโพสต์ไม่ตรงกับ URL
• ใครเห็นต่าง: ไม่มีคำคัดค้านอิสระในแหล่งข่าวชุดนี้ ข้อโต้แย้งของ OpenJDK เป็นการประเมินวิธีออกแบบทางเลือก
• ยังไม่รู้: วัน GA สถานะ LTS และผลทดสอบกับบริการไทย ไม่ควรเติมคำรับรองแทนข้อมูลที่ขาด
• ผลกับคุณ: ให้ทีมสำรวจงานคีย์และใบรับรองก่อนประเมินการย้าย อย่าอ้างยอดประหยัดที่ยังไม่ได้วัด
• ทำต่อ: ทดลองด้วยข้อมูลทดสอบ เก็บวิธีเดิมไว้ก่อน และไม่ส่งคีย์ส่วนตัวให้เว็บแปลงไฟล์ออนไลน์
• จับตา: กำหนดรุ่นจริง แผนสนับสนุนของผู้จำหน่าย และผลอ่านเขียนไฟล์ที่ทีมใช้งาน
• แหล่งอ้างอิง: 1 — JEP 542, 2 — Inside.java, 3 — โครงการ JDK 28, 4 — JEP 538