Re: Standardizing NO_NETWORK and USE_SYSTEM_DEPS environment variables
Simon Josefsson <[email protected]> Thu, 23 Jan 2025 20:42:25 +0100
| Newsgroups | dev.linux.lists.distributions |
|---|---|
| Message-ID | <[email protected]> |
--=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Celeste Liu <[email protected]> writes: >> 1) NO_NETWORK -- if it's set to a non-empty value, it requests that >> programs don't access the (TCP/IP) network. >=20 > It may be better to be named NO_INTERNET. Network is a confusing word in = Linux=20 > world. They can refer to something from only Internet to any protocols in= =20 > network subsystem, even include AF_NETLINK... I have been asked why my ud= ev is=20 > broken when my program is in a netns many times. Systemd also have to inf= orm=20 > this point in their document of PrivateNetwork. So use more limited word= =20 > Internet to avoid this. You are right. While my initial reaction to NO_NETWORK was positive, I have realized that there are subtle issues that is really hard to resolve. I considered adding support for NO_NETWORK to GNU InetUtils but I am beginning to feel that even NO_NETWORK has the same critical concerns that USE_SYSTEM_DEPS has: What exactly should NO_NETWORK mean to a package? What can it assume and what MUST it fail on? =2D Can it use localhost IP connectivity? =2D TCP? =2D Multicast? =2D Can it rely on non-DNS /etc/hosts name resolution working? =2D Can it rely on /etc/services being able to lookup network service names? =2D Is it allowed to inspect routing table on the system? etc Disabling all of those functionality when NO_NETWORK is probably not what was intended, right? When doing self-checks for 'ftp' and 'ftpd' it makes sense to start your newly built ftpd and test interop it against your newly built ftp binary. I don't think the intention is to forbid this. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQNoBAEWCAMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmeSm6EUHHNpbW9uQGpv c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh BLHSvRN1vst4TPT4xNc89jjFPAa+BQJl/YgIBQkLehFUAAoJENc89jjFPAa+CboA +wUa06RD5e5VTCxvSWtPS75Wq2qBeYGZnf0jvUMxa2n4AP4xkUeAPPnNuMsTm2fs FCDIGaEM2Yn6Vb2huzzT1Fw/BLgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0 +MTXPPY4xTwGvgUCZf2IKwUJC3oQqgCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE 8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J ENc89jjFPAa+GcYA/26YQY05bLtnXiIjTiAzrGQrRXxTHPA8Av7TDFHvIetWAP9s HSoU8OfTwmTiEnGwLlsV7QJclZg3YNz/Ypcp9TqQBrg4BFySz2oSCisGAQQBl1UB BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJl/YgwBQkLehDGAAoJENc89jjF PAa+phoA/jrDqIrl/55vUMBhIQv+TP635d2iCTEnyFmbUcP9+gh6APoDsXalVd2c OGxQtSC+TF8PkZMn1TLkJKAjVxr+xx40AgAKCRBRcisI/kdForTrAP93Z/L+Zfi/ CZVezQYY42lcFt8B76Z3aAJJWba4xoEsigD/ec9ltxS0FyjmfpYnp5833/Loy88J dr6gKEojtuezkQY= =b+Fo -----END PGP SIGNATURE----- --=-=-=--