[Mozilla Enterprise] Local XPI path in policies.json?

[Andrew J. Buehler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2021-02-03 at 18:34, Andrew J. Buehler wrote:

> On 2021-02-03 at 18:26, Andrew J. Buehler wrote:
> 
>> Does policies.json support local file paths for the Install 
>> property of the Extension policy under Windows? If so, what
>> syntax is necessary when specifying them?
>> 
>> 
>> Version 2.7 of the policy-templates document (which I believe is
>>  the relevant one for ESR 78.7) gives example paths of the forms
>>  "https://addons.mozilla.org/firefox/downloads/somefile.xpi" and
>>  "//path/to/xpi" - that is, a remote-URL path, and some form of 
>> filesystem-based path (not clear whether local or network).
>> 
>> It mentions that native paths are supported, which I infer to
>> mean that e.g. local paths of forms such as "/path/to/xpi" would
>> work on a Linux system.
>> 
>> 
>> However, when I try a local path of the form 
>> "C:\path\to\filename.xpi" on a Windows system - that being the
>> form native paths typically take on Windows - Firefox ESR 78.7.0
>> doesn't apply settings from the resulting JSON file, and
>> about:policies shows that there were errors parsing the file. A
>> UNC version of that local path ("\\C$\path\to\filename.xpi") -
>> the other Windows-native path form - gives the same result.
> 
> Unsurprisingly enough, not long after writing the above it
> occurred to me to try replacing the backslashes in that UNC path
> with slashes, to match the given non-URL example:
> "//C$/path/to/filename.xpi".
> 
> In my (so far brief) testing since that point, that appears to
> work. At the least it doesn't produce the JSON-parsing errors.

Further testing shows that this does not in fact work to load the XPI;
there are no apparent errors visible (though I didn't check the
consoles), and the rest of the JSON file is loaded and handled fine, but
the extension does not get installed. What does work is a file-protocol
version of the path:

"file:///C:/path/to/filename.xpi"

That's probably more consistent with expectable path syntaxes than the
form I had previously thought was working, but as can be observed, I
didn't find it intuitive as a form to try based on the given examples.

> If possible, I would request that actual Windows native path forms 
> be supported.
> 
> If that's not reasonably possible, I would request that at least
> the specific syntax necessary for specifying Windows paths be given
> in an example in the policy-templates document, for
> discoverability.

As such, these requests still stand.

- -- 
  Andrew J. Buehler
-----BEGIN PGP SIGNATURE-----

iQJJBAEBCgAzFiEEJCOqsZEc2qVC44pUBKk1jTQoMmsFAmAbP4wVHHdhbmRlcmVy
QGZhc3RtYWlsLmZtAAoJEASpNY00KDJrpd0P/Rh2f/Si5sLsP5Q7megiMmZwFR8d
rQoolwBbyyFoUdKLzLE3VWYugOVZJtGOJhUeEtVoTPq5l8csrZ5BWYZLuyyh4YYU
5IA5aj2KqQIVV0gqwk/rEUDYbR/rYDBHJJsMU8gv21VwYbGTwX8E8YwrWq5+jelg
WI8LftWU+YTR8gCGTMNWuWrkAKoPUZwKsGuhmtxmmsfVtq0JDH4R3ApbsXHyqSeS
dU2uEmvE0C+5VTvOpNQ2okP6WeKF+yXqDa/PJxHsBATV32cFgnqPDZrCQlnGE8v0
zLljlptaPWGzGMT75uC9IIynVZgt269wiyuob6aYXJhFJ7tkX779o5pL3pYptO4i
3l6rWvAv/aYdGHlBigRp+/WhVkDZtQ4eaT8bT+YNju8zTJyyYJuiZWf/5110nX+g
yj8Srw7ZR6sfB1sTHqu2WktLUNXUzbs4yNmIzm8TOvgBFx8WeeNPHVIASvfrs6dV
UVM1I5PWsdG1c7M17RF3unw4pAhe3h/ID2fkV72TwejU+nD1dU2MqRx+8bdDM0Je
fCJPWqCRPhwOi4p2t4i3d6BWr+VLEZyQCLFo/H0ZljloyJ8cRsbeHUPRHm6BTAA1
JSfFbe7lGvcJJGfnHYqwQS0n0fj+eFZvnelfhVSTfRDdCC6O6JkDTXtJKrVkHxnI
3+LydxMeDPW4Lf3w
=7CV2
-----END PGP SIGNATURE-----