Thanks, Remi,
1. We mainly have 2 kinds of situations:
a) Something like "uboot_ums_flash" which already in linaro lava tree. In the past, this can be overridden by job context. And I guess a lots of other variables which spread every corner of different jinja2 files. Huge I think, I really worried how lava can add so many keys in whitelist...
b) Something which just used in device jinja2 to control some different command in different situations. I know linaro accept upstreams for device-type, I have no idea if private lab's device jinja2 also useful for other people.
2. Sounds you guys will not rollback this commit because security issue. So two suggestions:
a) I don't know how this security issue could impact for an internal lab which not exposed to external internet. Anyway, if possible to add a configure to any settings to let admin to decide if we care this security issue?
b) If a) not easy to do or not accept, if possible this whitelist be stored in database or other persist file, so user can free to add his own keyword to whitelist, then even we will upgrade lava to later new version, we can still remain the keyword setting in the past, meanwhile user still can free to add any keyword to whitelist without upstream again and again for this hard coded whitelist, I don't think this make sense.
Please consider. BTW, as Tim Jaacks said in other thread: this limit not happen in multinode job, is it a bug, so next release we will also have this backdoor closed?
Regards, Larry
-----Original Message----- From: Lava-users lava-users-bounces@lists.lavasoftware.org On Behalf Of lava-users-request@lists.lavasoftware.org Sent: Tuesday, May 21, 2019 11:13 PM To: lava-users@lists.lavasoftware.org Subject: [EXT] Lava-users Digest, Vol 9, Issue 19
Caution: EXT Email
Send Lava-users mailing list submissions to lava-users@lists.lavasoftware.org
To subscribe or unsubscribe via the World Wide Web, visit https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.lava... or, via email, send a message with subject or body 'help' to lava-users-request@lists.lavasoftware.org
You can reach the person managing the list at lava-users-owner@lists.lavasoftware.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Lava-users digest..."
Today's Topics:
1. Re: Why make the decision to limit job context in lava master? (Remi Duraffort) 2. Re: timeouts for deploy vs http-download (Remi Duraffort) 3. Re: Using transfer overlay (Pete Dyer)
----------------------------------------------------------------------
Message: 1 Date: Tue, 21 May 2019 17:02:35 +0200 From: Remi Duraffort remi.duraffort@linaro.org To: lava-users lava-users@lists.lavasoftware.org Subject: Re: [Lava-users] Why make the decision to limit job context in lava master? Message-ID: CANJfhHeXiuVi02dMfmzeQ5EjnP=SqDymDNoyfwDB2XNN8ckodg@mail.gmail.com Content-Type: text/plain; charset="utf-8"
Hello,
we had to enforce the content of the context dictionary in order to fix a security issue that we found recently. The full details of the security issue will be disclosed when a CVE is available.
We know that this is annoying for many people so we tried to collect all the valid use cases before the previous release.
Which variables are you setting in the context? Is the corresponding code upstreamed?
Cheers
Le lun. 20 mai 2019 à 10:49, cnspring2002 cnspring2002@aliyun.com a écrit :
+1, we also have same issue, had to pending new version deploy.
Message: 1 Date: Mon, 20 May 2019 05:39:40 +0000 From: Larry Shen larry.shen@nxp.com To: "lava-users@lists.lavasoftware.org" lava-users@lists.lavasoftware.org Subject: [Lava-users] Why make the decision to limit job context in lava master? Message-ID: < DBBPR04MB63291E1DC4F5F202DEDFE16699060@DBBPR04MB6329.eurprd04.prod.out look.com
Content-Type: text/plain; charset="utf-8"
For 2019.04 version, we see next:
Job context
The schema validator is now checking the content of the `context` dictionary. Only the following keys are now allowed:
- `arch`, `boot_console`, `boot_root`, `cpu`, `extra_options`,
`guestfs_driveid`, `guestfs_interface`, `guestfs_size`, `machine`, `memory`, `model`, `monitor`, `netdevice`, `serial`, `vga`
- `bootloader_prompt`, `console_device`, `extra_kernel_args`,
`extra_nfsroot_args`, `kernel_loglevel`, `kernel_start_message`, `lava_test_results_dir`, `menu_interrupt_prompt`, `mustang_menu_list`, `test_character_delay`, `tftp_mac_address`
Jobs using keys that are not listed in this list will be rejected.
We usually set an customized context in job, and in device-type jinja2, use this context to just different value to set proper parameters. After this limit, all things break!
So, my question is:
lava could be designed to as a framework to give freedom to users to do their things as in the past, why we now enhance so many limits to users? And additional, and workaround for my scenario?
Regards, Larry
Lava-users mailing list Lava-users@lists.lavasoftware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist s.lavasoftware.org%2Fmailman%2Flistinfo%2Flava-users&data=02%7C01% 7Clarry.shen%40nxp.com%7C2ebbb071596f41c8816208d6ddfee338%7C686ea1d3bc 2b4c6fa92cd99c5c301635%7C0%7C0%7C636940484145033600&sdata=cpnWI8y6 NzawoUy%2BOtunqchIyXsaHO0ryYzPyJf3Gw0%3D&reserved=0
-- Rémi Duraffort LAVA Team, Linaro
Hello Larry,
- We mainly have 2 kinds of situations:
a) Something like "uboot_ums_flash" which already in linaro lava tree. In the past, this can be overridden by job context. And I guess a lots of other variables which spread every corner of different jinja2 files. Huge I think, I really worried how lava can add so many keys in whitelist...
Why do you have to update uboot_ums_flash in the job definition and not in the device dictionary? This sounds more like a device specific information instead of a job definition one. Anyway, having a long list of keys in the white list is not really a problem. This is only a python array, nothing more.
b) Something which just used in device jinja2 to control some different
command in different situations. I know linaro accept upstreams for device-type, I have no idea if private lab's device jinja2 also useful for other people.
Contributions are welcome. A rule of thumb for device-type integration/templates is often: is the device available for purchase by someone outside your company? If yes, then it's a good idea to upstream it. If not, then it's more a case-by-case decision.
2. Sounds you guys will not rollback this commit because security issue. So
two suggestions:
Sorry no :(
a) I don't know how this security issue could impact for an internal lab
which not exposed to external internet. Anyway, if possible to add a configure to any settings to let admin to decide if we care this security issue?
More details to come later on, but I don't think this is a good idea.
b) If a) not easy to do or not accept, if possible this whitelist be stored in database or other persist file, so user can free to add his own keyword to whitelist, then even we will upgrade lava to later new version, we can still remain the keyword setting in the past, meanwhile user still can free to add any keyword to whitelist without upstream again and again for this hard coded whitelist, I don't think this make sense.
I'm currently writing down a patch to allow admins to extend the white list with a variable in the settings.
Please consider. BTW, as Tim Jaacks said in other thread: this limit not
happen in multinode job, is it a bug, so next release we will also have this backdoor closed?
I'm fixing this second issue in https://git.lavasoftware.org/lava/lava/merge_requests/547 Thanks for reporting it.
Rgds
lava-users@lists.lavasoftware.org
-
Larry Shen -
Remi Duraffort