On Monday, July 20, 2020 4:52 PM, Wojtek Porczyk <[email protected]> wrote:
> On Sun, Jul 19, 2020 at 06:20:06PM +0000, WillyPillow wrote: > > > On another note, I'm wonder which fields are needed in the output of the > > "info" > > operation. Comparing my WIP code to DNF, I currently do not have the > > architecture [2], URL, licence, and description fields. This is due to > > `qubes.TemplateSearch` not currently returning those fields. > > For the packages in the official repos, those fields do not contain much > > information (in particular, the description field contains the same > > information > > as the summary), though I'm not sure if they might be useful in the future > > or > > for unofficial templates. > > I don't know, could you design that so that those can be added in the future > if need be? Those need to be understood and properly validated, because some > software might act upon that information. For example: Debian provides > a directory with licence texts, which allows for > /usr/share/common-licenses/$license, which smells path traversal. > Fedora's RPM guidelines is even worse, they support operators like "()", > "and", "or": > https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/ To include the information, all that is needed is to include it in the `queryformat` string of the qrexec call and read it in `qvm-template` (Aside from dealing with the newline issue [4] -- mentioned below.) As for validation, on our end, as we (AFAICT) only need to display the entry as is and don't need to parse it, we should be fine. For other programs parsing the information, IMO it should be up to the program in question to sanitize its inputs. This is because the fields contain, by design, arbitrary text, and my understanding of the linked article is that it's merely a guideline for Fedora repos instead of RPMs in general. > > One tricky thing is that the description may contain newlines, while `dnf > > repoquery` does not escape them at all [3]. This may mean that another > > method > > of querying the repo needs to be considered if the description is included. > > (Or > > use unconventional characters/strings as separators. In particular, I can't > > pass NULL characters in the arguments to DNF for obvious reasons.) > > Yes, another qrexec call is OK, provided this won't be too slow, i.e., to > display a list of 15 templates available you won't refresh the repo cache > 15 times... (Speaking of refreshing the repo cache, a `--refresh` option that forces this may need to be added, either as an option to the existing qrexec calls or as another call.) Creating another qrexec call is an interesting idea, but I'm unsure if it's really feasible performance-wise. In particular, running `dnf info` (which does not refresh the cache by default) on any package in `qubes-template-itl` takes almost a second on my machine. What I meant by "another method" is actually an alternative to `dnf repoquery`. The issue is that (AFAIK) DNF provides no methods other than `repoquery` to obtain a machine-readable form of the information (short of using the API from Python). However, it has the issue when dealing with newlines. IMO, the easiest way of doing this in terms of code changes is to modify `repoquery` so that it allows expanding `\0` as null characters. Currently, it already does similar replacements with `\n` and `\t`, and adding `\0` should only be a one-line change. However, I imagine that it would not be ideal to maintain a patched version of a package in VMs. Even if the patch gets merged upstream, it'll probably still take a few months for it to land in the next Fedora release. Other solutions I can think of right now are: - Maintain a separate modified copy of `repoquery.py`. From a first glance, it seems to be fairly self-contained, and the only internal thing it calls, AFAICT, is for i18n, which we don't care about in this context. - Write a simplified version of `repoquery` using the DNF API. Probably not too hard but feels like reinventing the wheel. > > [3]: Speaking of which, I'm also unsure what would happen if newlines appear > > in, say, the summary field. Maybe I can conduct some experiments about > > this... > > Certainly. Unfortunately, newlines in the summary field *does* break things. In particular, besides malformed repo XML files, a malformed package with newlines in the summary can also introduce erroneous newlines in the output of `repoquery`. Also, initial implementations of `qvm-template {info,search}` along with some other changes have been added to [the PR to core-admin-client](https://github.com/QubesOS/qubes-core-admin-client/pull/145). [4]: Technically, there may also be issues with the colon separator we currently use, though it's in essence the same issue. Thanks, WillyPillow > https://blog.nerde.pw/ > > PGP fingerprint = 6CCF 3FC7 32AC 9D83 D154 217F 1C16 C70E E7C3 1C84 > > Protonmail PGP = D02D CEFF ACE5 5A7B FF5D 871E 4004 1CB1 F52B 127E -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/CKKUfNQdNU4SkIVw93OHhdUzKaJUCFZalW9cC6uPy_JxtGvze2-Gw14kfPeYj4VshExmn0Kk7Ead3rka7o2nid3NV-46Sryk50m8GWtxTvg%3D%40nerde.pw.
publickey - [email protected] - 0xD02DCEFF.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
