On Apr 03, Marek Marczykowski-Górecki wrote:
Yes, self-explanatory names should be enough for simple functions. But still,
more complex functions, or with non-trivial arguments should have a docstring.
Okay. I'll go through again and make sure that's the case.
Right now windows compatibility (especially on the server side) isn't that
important.
W00t!
Nothing specifically against. But also be careful about resources - for
example rendering all the pages in parallel is a bad idea, since there
may be many of them (and in fact we do have a test that tries to convert
500 pages PDF file).
I was trying to come up with a limit on the number of simultaneous renderings.
Maybe something like half the total # of pages and if that's over some number
like 10 or something, then the limit is 10.
On the other hand, using a single DisposableVM means one malicious PDF could
access/modify other files you're trying to convert. IMO a better approach would
be to use separate DisposableVMs, but _independently_ optimize their resource
usage (for example you don't need the whole graphical stuff and most of other
service just to convert PDF -> RGB).
Good point. I'll read some more on Qubes to see how to go about doing that.
Also, I knew I would forget a question... While we can "sanitize" data sent by
the server, we can never really "verify" them since that would require parsing
the PDF client-side. So should variables received from the server always have
the "untrusted_" prefix? That's sort of the logic I'm going with right now.
Jason Phan
--
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 qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/20200403004500.3irxo2vpl54oai4t%40macbook.local.
