[qubes-devel] Internews short-term consultant opportunity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all, Internews is funding a short-term consultant to support Qubes OS development. The BASICS Specialist in Issue and Code Management is a remote, three-month, part-time contract. Please see the following link for details: https://chm.tbe.taleo.net/chm04/ats/careers/v2/viewRequisition?org=INTERNEWS=38=1186 - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl8ePVQACgkQ203TvDlQ MDAPpA//TTOQBzFwzT1x/XHAZB2S56tTxWhiiXZ2gaLz3RoUI9GBNf/jamGyrPbY Nz3gkHFl9JzfbQbH+1KD8RxKvw1yCcq6OB0bY8eB+4oNexbaulelGbr0mYuHn5VV Bfah7qOV20wZvemO2P+Fee3B2Qw4+eJEL0oVHmhGuSz6hHlU4/RxGVmTpluW/ak3 2Wl3S0oMhm5kpn8gVtVq6geVw5oH98KdA4EgLCB/Iosl9vcPEaJLSUazEP2vh/ZT Mda4z6qpDA6QUckQj9sPjrf3bF5amW0bNlvAwegD1Fmk+T1rcIXdmVZCFoYUaB46 mN9lQdAxqhoVeIF/vHrjz5JU2ebRxcWAtqLa9m/WzfxW42kU4ScvWY0R/NYW74Cf M1RHQHDD835WeEPy9uFSRXYnkeztYnfMmFKgoSHjCF8wzNvoAnfxt10KkLflNMLy rI9MKpA6tdNfKWiyXWJsDLBtFl6+s8L+PjIpQyhH4GcqKW0T+PFSPs56ESWXpTf0 gms19dvem56ux5H9OPf26kw5l5/VQW2y2mrnnfVAle17Z4wIq5I3EfEJmjWBYtlM KaZUfOFeQynsk+/FBDCzPVgxA+bMStm8JN3+p9r0T3ONpz/24IMhqA+y7FINJuE5 Tg8f4IWkMFunC12qV+XbGWiqsht0grce2yB6H9aQMJ5mgHvcR+0= =61PP -END PGP SIGNATURE- -- 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/1424fe7a-1558-cb00-1981-61a45a4519df%40qubes-os.org.
Re: [qubes-devel] Signed repository metadata and untrusted templates
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sun, Jul 26, 2020 at 09:03:35PM -0400, Demi M. Obenour wrote:
> On 2020-07-26 20:31, Marek Marczykowski-Górecki wrote:
> > On Sun, Jul 26, 2020 at 06:59:02PM -0400, Demi M. Obenour wrote:
> >> When looking at recent posts about template managers, two points came to
> >> mind:
> >
> >> ### Metadata Signing
> >
> >> Signing metadata would be awesome. Control over the repo listing
> >> allows delaying updates without being detected, and also allows for
> >> social engineering attacks. Debian manages to sign its metadata, so I
> >> don’t see any fundamental reason we can’t either.
> >
> > Debian actually signs metadata _instead of_ packages. This means a
> > debian package without matching signed metadata cannot be trusted[1]...
> >
> >> My understanding
> >> is that the metadata can be (deterministically) computed from the
> >> packages in the repo, which are themselves signed. Therefore, we
> >> could have a trusted VM that accepts RPM packages as input, checks
> >> the signatures, and then updates the metadata appropriately.
> >
> > In theory, it could be even simpler - the build VM could generate
> > repository metadata out of local repository copy, sign it and only then
> > upload to the server (currently it upload packages and generate metadata
> > on the remote host). One issue with that is that local copy would need
> > to be a full copy - currently we keep only latest packages in that
> > environment to save some disk space, but we keep all of them in the
> > public server (to allow explicit downgrades and also reproducing build
> > environment for specific package).
> >
> > Signing repository metadata has one more issue: we try to have an audit
> > trail what actually was signed (that's why all the build logs are
> > published for example). When signing repo metadata, it's much harder,
> > because besides the package you just built, you have a bunch of other
> > packages you need to include too. Perhaps some solution would be logging
> > difference between old and the new metadata? This is very similar issue
> > to the one we have with signing Debian metatadata:
> > https://github.com/QubesOS/qubes-issues/issues/2721
>
> Logging the delta seems to be a good option. If I recall correctly,
> RPM metadata is stored as XML, so we can just do a textual diff.
If the entries order is deterministic, then it should be enough indeed
(modulo different filenames - which are based on the content hash).
> How much disk space would be required? Is it enough to actually
> matter in practice?
For example R4.0 templates-itl repository takes 77GB, but just the
latest versions takes 15GB. For R4.0 dom0 packages ("current" repo) it
is 12GB vs 1.4GB. For other repositories the proportions are similar.
> > [1] Theoretically deb package format do support signatures, but Debian
> > project do not use that and the tooling is in quite poor state.
>
> If I recall correctly, they use signatures on *source* packages,
> but not on *binary* packages.
Yes. And those formats are completely different.
> >> ### Secure Installation of Untrusted Templates
> >
> >> Currently, templates are packaged via RPM, which allows executing
> >> arbitrary code on installation. However, the Qubes Admin API already
> >> allows importing a TemplateVM volume into dom0 without risking a dom0
> >> compromise. I see no reason why one needs to trust the packaging of a
> >> template any more than the template itself. If I publish a TemplateVM
> >> package, and my packaging infrastructure is compromised, the attacker
> >> will be able to compromise the TemplateVM packages I deliver, as
> >> well as any VMs based on those templates. They should not, however,
> >> be able to compromise any other VMs, much less dom0. Of course,
> >> a compromised TemplateVM is still bad, but it is not Game Over.
> >
> > This is one of the goals of the current template manager GSoC project.
> > The templates are still packages as RPMs, but those are used just as a
> > signed file containers - specifically, those packages will no longer be
> > installed using rpm tool, no pre/post/etc scripts from the package are
> > run, no package dependencies are handled etc. This makes it quite safe
> > to install such package with the new qvm-template directly in dom0, but
> > for added protection, it is also possible to use that tool outside of
> > dom0 (given proper Admin API permissions).
>
> What permissions will be needed?
Not much - creating new VM with TemplateVM class, and then various
operations on just that VM (importing disk image, settings
properties/features, starting it etc). This can be easily expressed with
"@tag:created-by-my-mgmt-vm" syntax. If you like, it should easy to
collect very specific set of permissions - you can simply call it once
then check the log.
> I am worried that they will be
> something like “allow RW to all”, which is almost as bad as dom0.
> This is compounded by “ask”
Re: [qubes-devel] Signed repository metadata and untrusted templates
On 2020-07-26 20:31, Marek Marczykowski-Górecki wrote: > On Sun, Jul 26, 2020 at 06:59:02PM -0400, Demi M. Obenour wrote: >> When looking at recent posts about template managers, two points came to >> mind: > >> ### Metadata Signing > >> Signing metadata would be awesome. Control over the repo listing >> allows delaying updates without being detected, and also allows for >> social engineering attacks. Debian manages to sign its metadata, so I >> don’t see any fundamental reason we can’t either. > > Debian actually signs metadata _instead of_ packages. This means a > debian package without matching signed metadata cannot be trusted[1]... > >> My understanding >> is that the metadata can be (deterministically) computed from the >> packages in the repo, which are themselves signed. Therefore, we >> could have a trusted VM that accepts RPM packages as input, checks >> the signatures, and then updates the metadata appropriately. > > In theory, it could be even simpler - the build VM could generate > repository metadata out of local repository copy, sign it and only then > upload to the server (currently it upload packages and generate metadata > on the remote host). One issue with that is that local copy would need > to be a full copy - currently we keep only latest packages in that > environment to save some disk space, but we keep all of them in the > public server (to allow explicit downgrades and also reproducing build > environment for specific package). > > Signing repository metadata has one more issue: we try to have an audit > trail what actually was signed (that's why all the build logs are > published for example). When signing repo metadata, it's much harder, > because besides the package you just built, you have a bunch of other > packages you need to include too. Perhaps some solution would be logging > difference between old and the new metadata? This is very similar issue > to the one we have with signing Debian metatadata: > https://github.com/QubesOS/qubes-issues/issues/2721 Logging the delta seems to be a good option. If I recall correctly, RPM metadata is stored as XML, so we can just do a textual diff. How much disk space would be required? Is it enough to actually matter in practice? > [1] Theoretically deb package format do support signatures, but Debian > project do not use that and the tooling is in quite poor state. If I recall correctly, they use signatures on *source* packages, but not on *binary* packages. >> ### Secure Installation of Untrusted Templates > >> Currently, templates are packaged via RPM, which allows executing >> arbitrary code on installation. However, the Qubes Admin API already >> allows importing a TemplateVM volume into dom0 without risking a dom0 >> compromise. I see no reason why one needs to trust the packaging of a >> template any more than the template itself. If I publish a TemplateVM >> package, and my packaging infrastructure is compromised, the attacker >> will be able to compromise the TemplateVM packages I deliver, as >> well as any VMs based on those templates. They should not, however, >> be able to compromise any other VMs, much less dom0. Of course, >> a compromised TemplateVM is still bad, but it is not Game Over. > > This is one of the goals of the current template manager GSoC project. > The templates are still packages as RPMs, but those are used just as a > signed file containers - specifically, those packages will no longer be > installed using rpm tool, no pre/post/etc scripts from the package are > run, no package dependencies are handled etc. This makes it quite safe > to install such package with the new qvm-template directly in dom0, but > for added protection, it is also possible to use that tool outside of > dom0 (given proper Admin API permissions). What permissions will be needed? I am worried that they will be something like “allow RW to all”, which is almost as bad as dom0. This is compounded by “ask” prompts for the Admin API being rather unhelpful: instead of prompting for *the VM that will be affected by the operation*, they prompt for the *VM the operation will be executed on*, which for the admin API is always dom0. Also, what is the advantage of RPMs over something like OpenBSD’s signify(1)-signed gzipped tar files? The RPM format seems rather bloated for this use-case. Sincerely, Demi -- 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/06d4a859-3360-c370-8e3f-085e3eb47b14%40gmail.com. signature.asc Description: OpenPGP digital signature
Re: [qubes-devel] Signed repository metadata and untrusted templates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jul 26, 2020 at 06:59:02PM -0400, Demi M. Obenour wrote: > When looking at recent posts about template managers, two points came to mind: > > ### Metadata Signing > > Signing metadata would be awesome. Control over the repo listing > allows delaying updates without being detected, and also allows for > social engineering attacks. Debian manages to sign its metadata, so I > don’t see any fundamental reason we can’t either. Debian actually signs metadata _instead of_ packages. This means a debian package without matching signed metadata cannot be trusted[1]... > My understanding > is that the metadata can be (deterministically) computed from the > packages in the repo, which are themselves signed. Therefore, we > could have a trusted VM that accepts RPM packages as input, checks > the signatures, and then updates the metadata appropriately. In theory, it could be even simpler - the build VM could generate repository metadata out of local repository copy, sign it and only then upload to the server (currently it upload packages and generate metadata on the remote host). One issue with that is that local copy would need to be a full copy - currently we keep only latest packages in that environment to save some disk space, but we keep all of them in the public server (to allow explicit downgrades and also reproducing build environment for specific package). Signing repository metadata has one more issue: we try to have an audit trail what actually was signed (that's why all the build logs are published for example). When signing repo metadata, it's much harder, because besides the package you just built, you have a bunch of other packages you need to include too. Perhaps some solution would be logging difference between old and the new metadata? This is very similar issue to the one we have with signing Debian metatadata: https://github.com/QubesOS/qubes-issues/issues/2721 [1] Theoretically deb package format do support signatures, but Debian project do not use that and the tooling is in quite poor state. > ### Secure Installation of Untrusted Templates > > Currently, templates are packaged via RPM, which allows executing > arbitrary code on installation. However, the Qubes Admin API already > allows importing a TemplateVM volume into dom0 without risking a dom0 > compromise. I see no reason why one needs to trust the packaging of a > template any more than the template itself. If I publish a TemplateVM > package, and my packaging infrastructure is compromised, the attacker > will be able to compromise the TemplateVM packages I deliver, as > well as any VMs based on those templates. They should not, however, > be able to compromise any other VMs, much less dom0. Of course, > a compromised TemplateVM is still bad, but it is not Game Over. This is one of the goals of the current template manager GSoC project. The templates are still packages as RPMs, but those are used just as a signed file containers - specifically, those packages will no longer be installed using rpm tool, no pre/post/etc scripts from the package are run, no package dependencies are handled etc. This makes it quite safe to install such package with the new qvm-template directly in dom0, but for added protection, it is also possible to use that tool outside of dom0 (given proper Admin API permissions). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl8eIGgACgkQ24/THMrX 1yzsdAf9HMcZtCT7QOROxI4osBOFSpzQ9eMMDDnSQdSvk2795iERYCvMD48vq/0x Coi2r1LNw0HM48VbZaQc6zH2jWp2ci4bRirmiK6yMFle/a0i438VzR/eB2TG5khu EhdO32Gtfca2yFIhQLvbIsVyfi1VLHTP8JH0lzXx1gShtm/U6Tbivic8/kRvcN+U 57qpyeCM4duukTkQiBgpnBvRyhTU+E1/mlqMxvh9UNm9UV8/53gC8j39TYAVrboZ /pvfeGYa6//xgF/Vatwkuz+CO41adFMy5N1NH4DNF+VjINhj0WDYdpOTpBYwQtFU 2r6ttKr/OopuBVxoqdQHqKqXPT4SDg== =+cFT -END PGP SIGNATURE- -- 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/20200727003136.GL1626%40mail-itl.
[qubes-devel] Signed repository metadata and untrusted templates
When looking at recent posts about template managers, two points came to mind: ### Metadata Signing Signing metadata would be awesome. Control over the repo listing allows delaying updates without being detected, and also allows for social engineering attacks. Debian manages to sign its metadata, so I don’t see any fundamental reason we can’t either. My understanding is that the metadata can be (deterministically) computed from the packages in the repo, which are themselves signed. Therefore, we could have a trusted VM that accepts RPM packages as input, checks the signatures, and then updates the metadata appropriately. ### Secure Installation of Untrusted Templates Currently, templates are packaged via RPM, which allows executing arbitrary code on installation. However, the Qubes Admin API already allows importing a TemplateVM volume into dom0 without risking a dom0 compromise. I see no reason why one needs to trust the packaging of a template any more than the template itself. If I publish a TemplateVM package, and my packaging infrastructure is compromised, the attacker will be able to compromise the TemplateVM packages I deliver, as well as any VMs based on those templates. They should not, however, be able to compromise any other VMs, much less dom0. Of course, a compromised TemplateVM is still bad, but it is not Game Over. Sincerely, Demi M. Obenour -- 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/0d00289e-0dc3-8e09-43e4-647998e8ed80%40gmail.com. signature.asc Description: OpenPGP digital signature
Re: [qubes-devel] [GSoC] Template Manager: Interactions w/ Repos
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sun, Jul 26, 2020 at 11:12:14PM +0200, Wojtek Porczyk wrote:
> On Sat, Jul 25, 2020 at 10:46:40AM +, WillyPillow wrote:
> > On Saturday, July 25, 2020 12:18 AM, Wojtek Porczyk
> > wrote:
> > > On Thu, Jul 23, 2020 at 05:45:56PM +, 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
> > ```
>
> - Yes, this breaks something and is not distinguishable from template manager.
> - No, it's not malformed, because it conforms to specification.
> - It's OK from security perspective: You cannot cause installation of anything
> the user didn't explicitly mean (by choosing an item on a list and/or
> accepting a signing key).
>
> To reiterate: in optimal case this should be avoided from the sending side,
> but it't not a very high priority. It would be also OK if the tool and
> specification did something like "only the first line with ':' skipped".
>
> The worst case is something can be shown on the list of available templates
> that actually cannot be installed.
Additionally, the canonical way to build template rpms (that are then
included in the repo) is linux-template-builder (or perhaps some other
template builder in some future) and we can easily make sure all the
(benign) package metadata matches the (possibly limited) specification of the
qvm-template.
> > > 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.)
>
> Sure.
>
> > > > 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.
>
> I think this should be one of the printable characters, so the output is easy
> to read and audit. Though ':' might well not be the best character, but there
> are others like '|' or even '!' (and I'd argue banning '!' from
Re: [qubes-devel] [GSoC] Template Manager: Interactions w/ Repos
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Sat, Jul 25, 2020 at 10:46:40AM +, WillyPillow wrote:
> On Saturday, July 25, 2020 12:18 AM, Wojtek Porczyk
> wrote:
> > On Thu, Jul 23, 2020 at 05:45:56PM +, 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
> ```
- - Yes, this breaks something and is not distinguishable from template manager.
- - No, it's not malformed, because it conforms to specification.
- - It's OK from security perspective: You cannot cause installation of anything
the user didn't explicitly mean (by choosing an item on a list and/or
accepting a signing key).
To reiterate: in optimal case this should be avoided from the sending side,
but it't not a very high priority. It would be also OK if the tool and
specification did something like "only the first line with ':' skipped".
The worst case is something can be shown on the list of available templates
that actually cannot be installed.
> > 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.)
Sure.
> > > 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.
I think this should be one of the printable characters, so the output is easy
to read and audit. Though ':' might well not be the best character, but there
are others like '|' or even '!' (and I'd argue banning '!' from descriptions
would do good to avoid shouting at people).
> > > [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) -seperated entries.
Having separator at the end gains nothing.
> Thanks,
> WillyPillow
Thank you for this week! Tomorrow Marmarek returns, so he'll carry on.
- --
