On Saturday, July 25, 2020 12:18 AM, Wojtek Porczyk <[email protected]> wrote:
> On Thu, Jul 23, 2020 at 05:45:56PM +0000, WillyPillow wrote:
>
> > One issue is that from the qrexec client side it is basically impossible to
> > distinguish between the two. (Consider the case where a field contains
> > `xxx\\na:b:c`.)
>
> If there are more colons that there are supposed to be, there is no need to
> distinguish anything anymore, just error out for "malformed input" or
> something.
>
> In Python I like to do it with tuple assingment:
>
> try:
> field1, field2, field3 = untrusted_line.split(':')
> except TypeError:
> raise ParseError('error message')
By "distinguish between the two" I meant correct input and malformed input.
Sorry for the confusion.
The point I was trying to make in that example was that when there are colons
*and* newlines, there could be cases like the following:
```
field1 = 'a'
field2 = 'b'
field3 = 'c\nd:e:f'
encoded = ':'.join([field1, field2, field3]) # a single entry
encoded_list = '\n'.join([encoded] * 10) # simulate multiple entries
# on the other side...
decoded_list = encoded_list.split('\n') # becomes 20 rows
for untrusted_line in decoded_list:
field1, field2, field3 = untrusted_line.split(':') # this does not error out
```
> It's as simple as that. The big advantage is that there aren't many ways to do
> something wrong.
>
> > Security-wise, this is unlikely to cause issues as an entity that can do
> > this
> > can probably modify the repo contents directly.
>
> The point is, we don't know. The repo content is untrusted, and yes, attacker
> can modify it. What counts is signature on RPM.
>
> > However, if the repo, by accident, does contain packages with, say, colons
> > in
> > summaries, it may be an issue usability-wise as it's hard to give meaningful
> > error messages when things break.
>
> "Malformed input" is OK. If we break loudly, template maintainers (the honest
> among them) won't publish such summary, because it will break.
The issue is that it's not always possible to detect such errors, as elaborated
above. Of course, as long as we keep this "wart" explicit, I'm okay with having
this as an "undefined behavior". (After all, the repo listing *is* considered
untrusted anyway.)
> > There's also the original issue with descriptions (assuming that we don't
> > omit
> > them), which contains newlines a lot of the time.
> > That being said, if we treat such errors as "repo errors" and leave to the
> > repo
> > maintainers to ensure that the fields follow a certain format, then we can
> > just
> > use a special character for the separator [5] and ban the character from the
> > fields.
>
> Yes, and IIUC the current proposal is to have ':' as that special character.
> Am I missing something?
The reason I'm bringing this up is twofold:
1. The idea of having the repo maintainer ensure such constraints have not been
explicitly brought up before AFAIK.
2. I'm unsure whether `:` is the best choice for this, as it's not an uncommon
character, and banning it might be undesirable. Something like ASCII 28-31
are possible alternatives.
> > [5]: The separator may also need to be placed at the end of the format
> > string.
>
> I don't think so.
If there is no such character at EOLs, then `\n` becomes another "special
character", as stuff would break when doing the `.split('\n')` step. If, on the
other hand, there is such a character, we can be sure that every entry consists
of exactly k (some positive number) <separator>-seperated entries.
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/YKt5E1YJyniPVpVDTwi0YuZNtjCb1niBZCF9S5Uooh08e8imke-gKKb-UvOqiLY7Ket6BndlvXe-vaFtZaPEeysXnq9r4sUMLr6DhyVDFI4%3D%40nerde.pw.
publickey - [email protected] - 0xD02DCEFF.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
