| Message ID | 20230910191445.564413-2-rs@ti.com |
|---|---|
| State | New |
| Headers | show |
| Series | bitbake-worker: remove the network flag | expand |
On Sun, 10 Sept 2023 at 21:15, <rs@ti.com> wrote: > -- ``[network]``: When set to "1", allows a task to access the network. By > - default, only the ``do_fetch`` task is granted network access. Recipes > - shouldn't access the network outside of ``do_fetch`` as it usually > - undermines fetcher source mirroring, image and licence manifests, software > - auditing and supply chain security. These reasons still stand. The only correct solution is to write a fetcher that can be used in SRC_URI. This was communicated to you previously. So please: lay out what is it exactly you're doing outside of do_fetch that needs the network, and we'll try to figure out how to engineer it with a fetcher. Alex
On Sun, 2023-09-10 at 14:14 -0500, rs@ti.com wrote: > From: Randolph Sapp <rs@ti.com> > > The network flag does not respect proxies as the fetch stage does [1]. > As such it only works for some users at the whim of the recipe writer. > > This introduces an issue downstream as the build results are now > dependent on the network architecture of the builder, the recipe in > question, and the combination of proxy variables they choose to export > in addition to the normal host variables that affect builds (host tool > version, build environment, etc). > > This is far more indeterminate than a build system that properly exports > proxy variables. If abuse of the network tag is an issue, then the > network tag should be removed in it's current state. > > [1] https://lists.openembedded.org/g/bitbake-devel/topic/100924096 > > Signed-off-by: Randolph Sapp <rs@ti.com> > --- > > The logical followup to my last patch, even if it does seem a little extreme. My logical followup is to say no, I'm not merging this. The reason is self evident. We should ensure custom fetch code correctly accounts for proxies. Cheers, Richard
On 9/10/23 14:33, Alexander Kanavin wrote: > On Sun, 10 Sept 2023 at 21:15, <rs@ti.com> wrote: > >> -- ``[network]``: When set to "1", allows a task to access the network. By >> - default, only the ``do_fetch`` task is granted network access. Recipes >> - shouldn't access the network outside of ``do_fetch`` as it usually >> - undermines fetcher source mirroring, image and licence manifests, software >> - auditing and supply chain security. > > These reasons still stand. > > The only correct solution is to write a fetcher that can be used in > SRC_URI. This was communicated to you previously. So please: lay out > what is it exactly you're doing outside of do_fetch that needs the > network, and we'll try to figure out how to engineer it with a > fetcher. > > Alex I'm aware of the proper solution, but this will address the issues of network flag abuse that other layers are introducing. My issue is that by exposing the network flag like this any layer can come along an introduce build complications. If that's the case, why expose this flag at all? Randolph
On Sun, 10 Sept 2023 at 21:37, Randolph Sapp <rs@ti.com> wrote: > I'm aware of the proper solution, but this will address the issues of > network flag abuse that other layers are introducing. > My issue is that by exposing the network flag like this any layer can > come along an introduce build complications. If that's the case, why > expose this flag at all? Which other layers? Do tell us, so we can recommend everyone to avoid using them. Poorly maintained layers do insane stuff all the time. This doesn't mean we shouldn't highlight bad practices in a very clear manner, and make them complicated or impossible whenever possible. Alex
diff --git a/bin/bitbake-worker b/bin/bitbake-worker index 451e6926..71ff0516 100755 --- a/bin/bitbake-worker +++ b/bin/bitbake-worker @@ -270,12 +270,11 @@ def fork_off_task(cfg, data, databuilder, workerdata, extraconfigdata, runtask): bb.utils.set_process_name("%s:%s" % (the_data.getVar("PN"), taskname.replace("do_", ""))) - if not bb.utils.to_boolean(the_data.getVarFlag(taskname, 'network')): - if bb.utils.is_local_uid(uid): - logger.debug("Attempting to disable network for %s" % taskname) - bb.utils.disable_network(uid, gid) - else: - logger.debug("Skipping disable network for %s since %s is not a local uid." % (taskname, uid)) + if bb.utils.is_local_uid(uid): + logger.debug("Attempting to disable network for %s" % taskname) + bb.utils.disable_network(uid, gid) + else: + logger.debug("Skipping disable network for %s since %s is not a local uid." % (taskname, uid)) # exported_vars() returns a generator which *cannot* be passed to os.environ.update() # successfully. We also need to unset anything from the environment which shouldn't be there diff --git a/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst b/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst index 58975f4c..b35c332c 100644 --- a/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst +++ b/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst @@ -1519,12 +1519,6 @@ functionality of the task: released. You can use this variable flag to accomplish mutual exclusion. -- ``[network]``: When set to "1", allows a task to access the network. By - default, only the ``do_fetch`` task is granted network access. Recipes - shouldn't access the network outside of ``do_fetch`` as it usually - undermines fetcher source mirroring, image and licence manifests, software - auditing and supply chain security. - - ``[noexec]``: When set to "1", marks the task as being empty, with no execution required. You can use the ``[noexec]`` flag to set up tasks as dependency placeholders, or to disable tasks defined