HTTPS ಮತ್ತು VPN ನೀವು ಸ್ಥಾಪಿಸುವ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ದೃಢೀಕರಿಸುವುದಿಲ್ಲ

ಒಂದು ನವೀಕರಣ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಥ್ರೆಡ್ನಲ್ಲಿನ ಸಲಹೆ ಪರಿಚಿತ ಹಾದಿಯಲ್ಲಿ ಸಾಗುತ್ತದೆ: ಸಂಚಾರ VPN ಮೂಲಕ ಹೋಗುತ್ತದೆ, ಹಾಗಾಗಿ ಡೌನ್ಲೋಡ್ ನಂಬಲರ್ಹವಾಗಿರಬೇಕು, ಮತ್ತು ದೋಷವನ್ನು ದಾಟಲು ಸಹಿ ಪರಿಶೀಲನೆ ಸಡಿಲಗೊಳಿಸಲಾಗುತ್ತದೆ। ಎರಡು ಪ್ರತ್ಯೇಕ ಕಲ್ಪನೆಗಳು ಒಂದೇ ವಾಕ್ಯದಲ್ಲಿ ಬೆರೆತುಹೋಗಿವೆ। ಗೂಢಲಿಪೀಕರಣವು ಎರಡು ತುದಿಗಳ ನಡುವಿನ ಮಾರ್ಗವನ್ನು ರಕ್ಷಿಸುತ್ತದೆ; ದೃಢೀಕರಣವು ಬೈಟ್ಗಳು ನೀವು ಉದ್ದೇಶಿಸಿದ ಪ್ರಕಾಶಕರಿಂದ ಬಂದವೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ। ಸುರಂಗವು ಮೊದಲನೆಯದನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ಎರಡನೆಯದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ।

ಲಕ್ಷಣ ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ಹೋಸ್ಟ್ನಲ್ಲಿ, ಒಂದು ಭಂಡಾರದಲ್ಲಿ ಪರಿಶೀಲನಾ ದೋಷವಾಗಿದ್ದು, ಉಳಿದದ್ದು ಸಾಮಾನ್ಯವಾಗಿ ನವೀಕರಣಗೊಳ್ಳುತ್ತದೆ। ಆ ಆಕಾರವೇ ಜಾಲ ಮಾರ್ಗ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಮತ್ತು ಭಿನ್ನಾಭಿಪ್ರಾಯ ನಂಬಿಕೆಯ ಬಗ್ಗೆ ಎಂದು ಹೇಳುತ್ತದೆ।

ಬೇರೆ ಬೇರೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುವ ಎರಡು ನಿಯಂತ್ರಣಗಳು

ಸಾಗಣೆ ಭದ್ರತೆಯು ಈ ಸಂಪರ್ಕದ ಇನ್ನೊಂದು ತುದಿಯಲ್ಲಿ ಯಾರಿದ್ದಾರೆ ಮತ್ತು ಮಾರ್ಗದಲ್ಲಿ ಯಾರಾದರೂ ಅದನ್ನು ಓದಬಹುದೇ ಅಥವಾ ಬದಲಾಯಿಸಬಹುದೇ ಎಂದು ಉತ್ತರಿಸುತ್ತದೆ। ಪ್ಯಾಕೇಜ್ ದೃಢೀಕರಣವು ಈ ಕಲಾಕೃತಿಯನ್ನು ನೀವು ಸಂರಚಿಸಿದ ಪ್ರಾಧಿಕಾರ ಪ್ರಕಟಿಸಿದೆಯೇ ಎಂದು ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ನೀವು ನಿಯಂತ್ರಿಸದ ಕನ್ನಡಿಯ ಮೂಲಕ ಡೌನ್ಲೋಡ್ಗೆ ಅದು ತಡೆದುಕೊಳ್ಳಬೇಕು।

ಆ ಪ್ರಶ್ನೆಗಳು ಅಂಚುಗಳಲ್ಲಿ ಮಾತ್ರ ಜೋಡಣೆಯಾಗುತ್ತವೆ। ಕನ್ನಡಿಯ ಮೇಲಿನ ಸರಿಯಾದ ಪ್ರಮಾಣಪತ್ರವು ಕನ್ನಡಿಯೇ ಕನ್ನಡಿ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ; ಅದು ಕನ್ನಡಿಯಲ್ಲಿ ಬದಲಾಗದ ಪ್ರಕಾಶಕ ವಿಷಯವಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ। ಸಹಿ ಮಾಡಿದ ಪ್ಯಾಕೇಜ್ ಪ್ರಕಾಶಕರು ಅದಕ್ಕೆ ಸಹಿ ಮಾಡಿದ್ದಾರೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ; ಅದು ಜಾಲವು ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ತಲುಪಿಸಿತು ಅಥವಾ ನೀವು ತೋರಿಸಿದ ಭಂಡಾರ ನಿಮ್ಮ ಸಂಸ್ಥೆ ಅನುಮೋದಿಸಿದ್ದು ಎಂದು ಹೇಳುವುದಿಲ್ಲ।

ಜನರು ಪರಿಶೀಲನೆಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ ಸೃಷ್ಟಿಸುವ ವೈಫಲ್ಯ ಸ್ಥಿತಿಯು ಎರಡನೆಯ ಭರವಸೆಯ ಶಾಶ್ವತ ನಷ್ಟ, ಒಂದು ಯಶಸ್ವಿ ಡೌನ್ಲೋಡ್ಗೆ ಬದಲಾಗಿ। ಆ ವಿನಿಮಯವು ಅದು ಮುಖ್ಯವಾದ ದಿನದವರೆಗೆ ಕಾಣುವುದಿಲ್ಲ।

apt ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ

APT ಯ ಮಾದರಿ ದೃಢೀಕೃತ ಆರ್ಕೈವ್ ಸರಪಳಿ। ಸಹಿ ಮಾಡಿದ ಬಿಡುಗಡೆ ಮೆಟಾಡೇಟಾ ಚೆಕ್ಸಮ್ ಮೂಲಕ ಪ್ಯಾಕೇಜ್ ಸೂಚಿಗಳಿಗೆ ಕರೆದೊಯ್ಯುತ್ತದೆ, ಮತ್ತು ಆ ಸೂಚಿಗಳು ಚೆಕ್ಸಮ್ ಮೂಲಕ ಪ್ರತ್ಯೇಕ ಪ್ಯಾಕೇಜ್ ಫೈಲ್ಗಳಿಗೆ ಕರೆದೊಯ್ಯುತ್ತವೆ। ಸರಪಳಿಯ ಪರಿಶೀಲನೆಯೇ ಕನ್ನಡಿಯನ್ನು ನಂಬಲಾಗದದ್ದಾಗಿ ಆದರೆ ಬಳಸಬಹುದಾದದ್ದಾಗಿ ಮಾಡುತ್ತದೆ: ಕನ್ನಡಿಯು ತನಗಿಷ್ಟವಾದ್ದನ್ನು ನೀಡಬಹುದು, ಮತ್ತು ಮೆಟಾಡೇಟಾದ ಸಹಿಯೇ APT ಅದನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ।

ಇದು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪ್ರತಿ ಸ್ಥಾಪಿತ ಪ್ಯಾಕೇಜಿನಲ್ಲಿ ನಿರ್ವಾಹಕರ ಸಹಿಯನ್ನು ಪರಿಶೀಲಿಸುವುದಕ್ಕೆ ಸಮಾನವಲ್ಲ, ಮತ್ತು ಈ ವ್ಯತ್ಯಾಸವೇ ದೋಷ ವರದಿಗಳಲ್ಲಿ «ಪ್ಯಾಕೇಜ್ ಸಹಿ ಮಾಡಲಾಗಿದೆ» ಮತ್ತು «ಆರ್ಕೈವ್ ದೃಢೀಕೃತವಾಗಿದೆ» ಪರಸ್ಪರ ಬದಲಾಗಿ ಬಳಸಲ್ಪಡುವುದಕ್ಕೆ ಕಾರಣ, ಆದರೂ ಅವು ಬೇರೆ ಬೇರೆ ವಿಷಯಗಳನ್ನು ಸೂಚಿಸುತ್ತವೆ।

apt-get update
apt-cache policy
apt-config dump | grep -iE 'AllowInsecure|AllowDowngrade'

ನವೀಕರಣದ ಔಟ್ಪುಟ್ ಓದಿ, ಕೇವಲ ನಿರ್ಗಮನ ಸಂಕೇತವಲ್ಲ। APT ಮೆಟಾಡೇಟಾ ವಿಫಲವಾದ ಭಂಡಾರದ ಹೆಸರನ್ನು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಆ ಹೆಸರೇ ತನಿಖೆ ಮಾಡಬೇಕಾದ ಗಡಿ। ಸಹಿ ಪರಿಶೀಲನೆ ಇಲ್ಲದೆ ನಂಬಲರ್ಹ ಎಂದು ಗುರುತಿಸಿದ ಭಂಡಾರ, ಅಥವಾ ಅಸುರಕ್ಷಿತ ಭಂಡಾರಕ್ಕೆ ತಿದ್ದುಪಡಿ, ಯಾರೋ ತೆಗೆದುಕೊಂಡ ಸಂರಚನಾ ನಿರ್ಧಾರ ಮತ್ತು ಅವರು ಅದನ್ನು ವಿವರಿಸಲು ಸಾಧ್ಯವಾಗಬೇಕು।

ತಾಜಾತನವೂ ಮತ್ತೊಂದು ಪ್ರತ್ಯೇಕ ಗುಣ। ಮಾನ್ಯವಾಗಿ ಸಹಿ ಮಾಡಿದ ಮೆಟಾಡೇಟಾ ಫೈಲ್ ಕಳೆದ ವಾರ ನೋಡಿದ್ದಕ್ಕಿಂತ ಹಳೆಯದಾಗಿರಬಹುದು, ಆದ್ದರಿಂದ ಬಿಡುಗಡೆ ಮೆಟಾಡೇಟಾ ಅವಧಿ ಹೊಂದಿದೆ ಮತ್ತು ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್ನ ಗಡಿಯಾರ ಸಮಸ್ಯೆಯು ಕೀಲಿ ಸಮಸ್ಯೆಗಳಂತೆ ಕಾಣುವ ಪರಿಶೀಲನಾ ದೋಷಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು।

dnf5 ಪ್ರತ್ಯೇಕವಾಗಿ ಏನನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ

RPM ಭಾಗವು ಎರಡು ವಿಭಿನ್ನ ಸ್ವಿಚ್ಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ, ಮತ್ತು ಅವನ್ನು ಗೊಂದಲಗೊಳಿಸುವುದು ಇನ್ನೊಂದು ದಿಕ್ಕಿನಲ್ಲಿ ಅದೇ ರೀತಿಯ ದೋಷವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ। ಒಂದು ಪ್ಯಾಕೇಜ್ ಫೈಲ್ಗಳು ಮಾನ್ಯ ಸಹಿ ಹೊಂದಿರಬೇಕೇ ಎಂದು ನಿಯಂತ್ರಿಸುತ್ತದೆ; ಇನ್ನೊಂದು ಭಂಡಾರ ಮೆಟಾಡೇಟಾ ಸಹಿ ಆಗಿರಬೇಕೇ ಎಂದು ನಿಯಂತ್ರಿಸುತ್ತದೆ। ಅವನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಹೊಂದಿಸಬಹುದು, ಮತ್ತು ಒಂದರಲ್ಲಿ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಇನ್ನೊಂದರಲ್ಲಿ ಸಡಿಲವಾಗಿರುವ ವ್ಯವಸ್ಥೆ ಇರಬಹುದು।

dnf5 config-manager --dump 2>/dev/null | grep -iE 'gpgcheck|repo_gpgcheck'
rpm -q --qf '%{NAME} %{SIGPGP:pgpsig}\n' bash

ಪ್ಯಾಕೇಜ್ ಪ್ರಶ್ನೆಯು ಸ್ಥಾಪಿತ ಪ್ರತಿಯ ಸಹಿ ಮೆಟಾಡೇಟಾ ಹೇಗಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಇದು ಕಟ್ಟುನಿಟ್ಟಿನ ಪ್ರತಿಪಾದನೆ ಮಾಡುವ ಸಂರಚನಾ ಫೈಲ್ ವಿರುದ್ಧ ಉಪಯುಕ್ತ ವಾಸ್ತವ ಪರಿಶೀಲನೆ। ಅದು ಹೇಳದಿರುವುದು ವಿತರಣೆಯ ಬೆಂಬಲಿತ ನೀತಿ, ಮತ್ತು ವೇದಿಕೆಯ ಸಾಮಾನ್ಯ «GPG ಸಕ್ರಿಯಗೊಳಿಸಿ» ಸೂಚನೆಯ ಬದಲು ಅದನ್ನೇ ಅನುಸರಿಸಬೇಕು।

ಎರಡು ನಿರ್ವಾಹಕರು ಭಿನ್ನವಾಗುವಲ್ಲಿ ವ್ಯತ್ಯಾಸವು ವಾಸ್ತುಶಿಲ್ಪದ್ದು, ಒಂದು ದುರ್ಬಲ ಎಂಬ ಸಂಕೇತವಲ್ಲ। ಎರಡೂ ಪ್ರಕಾಶಕ ವಿಷಯವನ್ನು ದೃಢೀಕರಿಸುತ್ತವೆ; ಅವು ಸಹಿಯನ್ನು ಸರಪಳಿಯ ಬೇರೆ ಬೇರೆ ಬಿಂದುಗಳಲ್ಲಿ ಇಡುತ್ತವೆ।

ಸುರಂಗ ಏನನ್ನು ಸೇರಿಸುತ್ತದೆ ಮತ್ತು ಏನನ್ನು ಇಲ್ಲ

VPN ಅಗತ್ಯವಾದ ಮಾರ್ಗವನ್ನು ಒದಗಿಸಬಹುದು, ನವೀಕರಣ ಸಂಚಾರವನ್ನು ನಂಬಲಾಗದ ಪ್ರವೇಶ ಜಾಲದಿಂದ ಹೊರಗಿಡಬಹುದು ಮತ್ತು ಸ್ಥಳೀಯ ವೀಕ್ಷಕನು ನೋಡುವುದನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು। ಇವು ನಿಜವಾದ ಕಾರ್ಯಾಚರಣಾ ಲಾಭಗಳು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಪ್ರಕಾಶಕ ದೃಢೀಕರಣವಲ್ಲ।

HTTPS ತನ್ನದೇ ಭರವಸೆಯನ್ನು ಸೇರಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಅನಿಸುವುದಕ್ಕಿಂತ ಸಂಕುಚಿತ। ಅದು ನೀವು ಸಂಪರ್ಕಿಸಿದ TLS ತುದಿಯನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ। ಆ ತುದಿ ಕನ್ನಡಿಯಾಗಿದ್ದರೆ, ನೀವು ಕನ್ನಡಿಯನ್ನು ದೃಢೀಕರಿಸಿದ್ದೀರಿ, ಅದು ನೀಡುವ ಆರ್ಕೈವ್ ವಿಷಯವನ್ನಲ್ಲ। ಸಹಿ ಮಾಡಿದ ಮೆಟಾಡೇಟಾ ಸರಪಳಿ ಇರುವುದೇ ನಿಖರವಾಗಿ ಈ ಸಂದರ್ಭಕ್ಕಾಗಿ।

ಎರಡೂ ನಿಯಂತ್ರಣಗಳಲ್ಲಿ ಯಾವುದೂ ಲಭ್ಯತೆಯ ಭರವಸೆ ನೀಡುವುದಿಲ್ಲ। ಜಾಲವು ವಿತರಣೆಯನ್ನು ನಿರಾಕರಿಸಬಹುದು, ಮತ್ತು ದೃಢೀಕೃತ ವಸ್ತು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹೊಸದಲ್ಲ। ಬೀಗದ ಚಿಹ್ನೆಯಿರುವುದರಿಂದ ಊಹಿಸುವ ಬದಲು ಪ್ಯಾಕೇಜ್ ನಿರ್ವಾಹಕರ ಸ್ವಂತ ತಾಜಾತನ ನೀತಿಯನ್ನು ಬಳಸಿ।

ವಿಫಲವಾದ ಗಡಿಯನ್ನು ನಿರ್ಣಯಿಸಿ

ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಹಂತವನ್ನು ಹೆಸರಿಸಿ: DNS ವಿಭಜನೆ, ಪ್ರಾಕ್ಸಿ ಅಥವಾ ಮಾರ್ಗ, TLS ತುದಿಯ ಗುರುತು, ಆರ್ಕೈವ್ ದೃಢೀಕರಣ, ಪ್ಯಾಕೇಜ್ ಸಹಿ ಪರಿಶೀಲನೆಗಳು, ಅಥವಾ ಸ್ಥಾಪನೆ। ಪ್ರತಿಯೊಂದಕ್ಕೂ ಬೇರೆಯಾದ ದೋಷ ಆಕಾರ ಮತ್ತು ಬೇರೆಯಾದ ಮಾಲೀಕನಿದ್ದಾನೆ।

ಜಾಲ ಮಾರ್ಗದ ದುರಸ್ತಿಯು ಎಂದಿಗೂ ಅಪರಿಚಿತ ಸಹಿ ಕೀಲಿಯನ್ನು ನಂಬಲರ್ಹ ಎಂದು ಘೋಷಿಸುವುದು, ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುವುದು, ಅಥವಾ ನೀವು ಕೇಳದ ಭಂಡಾರ ಸಂರಚನೆಯನ್ನು ಒಪ್ಪುವುದನ್ನು ಒಳಗೊಂಡಿರಬಾರದು। ಕೀಲಿ ನಿಜವಾಗಿಯೂ ತಿರುಗಿದ್ದರೆ, ವಿತರಣೆ ಅಥವಾ ಭಂಡಾರದ ಮಾಲೀಕರು ಹೊಸ ಕೀಲಿಯನ್ನು ನೀವು ಪರಿಶೀಲಿಸಬಹುದಾದ ಮಾರ್ಗದಲ್ಲಿ ಪ್ರಕಟಿಸುತ್ತಾರೆ, ಮತ್ತು ಅದೇ ಅನ್ವಯಿಸಬೇಕಾದ ತಿದ್ದುಪಡಿ।

ಯಾವ ಗಡಿ ವಿಫಲವಾಯಿತು ಮತ್ತು ಅದರ ಮಾಲೀಕರು ಯಾರು ಎಂದು ಬರೆಯಿರಿ। ಮುಂದಿನ ನವೀಕರಣ ವೈಫಲ್ಯ ಬೇರೆ ಗಡಿಯಲ್ಲಿ ಇರುತ್ತದೆ, ಮತ್ತು ಪಟ್ಟಿ ಇರುವುದು ಅದನ್ನು ಸುರಂಗ ನವೀಕರಣಗಳನ್ನು ಸುರಕ್ಷಿತಗೊಳಿಸುತ್ತದೆಯೇ ಎಂಬ ಇನ್ನೊಂದು ಚರ್ಚೆಯ ಬದಲು ಐದು ನಿಮಿಷದ ನಿರ್ಣಯವಾಗಿಸುತ್ತದೆ।