Bug#1010256: ITP: rust-ahash -- non-cryptographic hash function

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-devel@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-ahash
  Version : 0.7.6
  Upstream Author : Tom Kaitchuck 
* URL : https://github.com/tkaitchuck/ahash
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : non-cryptographic hash function

 AHash is the fastest, DOS resistant hash currently available in Rust.
 AHash is intended *exclusively* for use in in-memory hashmaps.
 .
 AHash's output is of high quality
 but aHash is **not** a cryptographically secure hash.

This package is needed by ITP packages atomic-data-rust and fractal.
It will be maintained in the collaborative debian section at salsa,
here: https://salsa.debian.org/debian/rust-ahash


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmJpAKQACgkQLHwxRsGg
ASErww/+MO95S8ls8+UQKNMhag9M/z3V9DP4+B29Skwxy+PbegpDd+2eIFeZb9P5
YMnVtNyI4wRfrYug4NmTzGxHM7tu1GHKpXzUesCtirihFUaCl7oXkGBqWtjvjJWl
vIN9Y5NibQQPl+Br07HI/u5wEUn6kZgRHry4hJZV6E4nvY4RKgOOwQlLAuikqOZ6
Enr65fjv4P+zyWfH7GR7V3XwZKxcrE5ISL+l3piZnKijLeZUsQAfA2s95sQrIeHb
QyQ2b/Q5zoARe7ypvOzpcyfneLJ0gLB0/WG25fuVIg5fE3CFo1UIhsqmD5qekTxL
CPUdWidkHgQ8mzYC6BlrOEw3ETUEydGodfEc1jiaWDENj74kTgcC5QR4M358JdLj
iy+N+WlZv1UURgVXLU5ek41upzI9uFXdpk0Fu4f3Qk6o9juK1rjW2oRKZn3ZR8jH
kvy+6oUa5zU/IyVznFemwedUy2sPdihmqGNg7KXHv58XhWDYnOAQMo+tnvuJJHT0
6V7EBGKg8Rd1XOjYkJq+6UMDTY9JsL8ah+DpmNeub3urtVb6c66repYkrFQELlzK
I/e6BqR7RSQoShjdGz153niR3TReV0qJSQeR79RtLogOnU05rqLtKnUw8yXWrhdh
cfUcWWs7i8+VBqKqt+LyhEnC4/Ec/hEYM+3fml5/N+x7TRvEJHs=
=cTbd
-END PGP SIGNATURE-

Bug#1010257: ITP: rust-xor-name -- DHT-optimized array function

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-devel@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-xor-name
  Version : 4.0.1
  Upstream Author : MaidSafe.net limited
* URL : https://github.com/maidsafe/xor_name
* License : BSD-3-clause or Expat
  Programming Lang: Rust
  Description : DHT-optimized array function

This package is needed for ITP project safe-network.
It will be maintained in the collaborative debian section of salsa,
here: https://salsa.debian.org/debian/rust-xor-name

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmJpDqQACgkQLHwxRsGg
ASFEXQ/+NX+zKLEIaRKwCnrrCbfI6QSWoYhRcZCz40LwB7x6EEZJBZt5I+uV81l7
3OgAdjznDR//tWiUPqCJ1j1323uZaLWTcEKE4aTynEk+S3hluJ0lBezWmBe9zFOK
9bCxKU3nYDqiipfaYOy7PsRh+htHSBbTaxodqeejuLmdj82vUjBVLhYDj32Ne1Km
NGWQekvO96u97srigexfd47TxrKrzmPccUSB5++nW/BzSUIAHas/nkORkgqMzG87
l8agF/I9Fc1IxsM1s3evQ/YePM23Z9vcJNpVVDefG5RQeYYRv1B3P2xO4pMcfGSn
8fJPqys4ECc4i7s0oMgLkn9fi6zQgAmcwpOrsPq2x3Xbt7qVdmIKnRSW9vMuSmjz
o6tSptgybFsDAKQbgvhB0lgVIoh78pbdeoFOdVGr6ibKiN3j+oDAjGSqbTXYZVAx
8Y+/dcxG1SkHO2gCUu5VWkR5pS5b48MXT+Cqwzn3giI9XONVUuz53gpjhaFa9c1m
WXyLLi9kEGRbYKuq8/swJ/5m5XHsFTlM1euWGu+rpO6px6alH5b38EJirpsktfkd
7tlZjjLe0xLh1tYMLeNGDNWEh7ZHs02j3voPUU2LykYZEvYgeTKXj20jAldvbYNE
E8hPkUxfX52VOcrdQbKa9YRJJjf+HMFKR2vPDeYZ0eyeU5WDtg4=
=i8hK
-END PGP SIGNATURE-

Bug#1010267: ITP: tractor -- Setup an onion routing proxy

[Danial Behzadi]

Package: wnpp
Severity: wishlist
Owner: Danial Behzadi 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: tractor
  Version : 3.12
  Upstream Author : Danial Behzadi 
* URL : https://framagit.org/tractor/tractor/
* License : GPL
  Programming Lang: Python
  Description : Setup an onion routing proxy

 This package uses Python stem library to provide
 a connection through the onion proxy and sets up
 proxy in user session, so you don't have to mess
 up with TOR on your system anymore.

 - I use this package to setup some tor connections in user
   session, quickly turn bridges on/off or setting/unsetting
   tor proxy in my session.
 - I will maintain the software and the package for Debian,
   but since I'm not a DD yet, I'll need a sponsor for it.108

Bug#1010268: ITP: node-sinclair-typebox -- JSON Schema Type Builder with Static Type Resolution for TypeScript

[Yadd]

Package: wnpp
Severity: wishlist
Owner: Yadd 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: node-sinclair-typebox
  Version : 0.23.4
  Upstream Author : sinclairzx81 
* URL : https://github.com/sinclairzx81/typebox
* License : Expat
  Programming Lang: JavaScript
  Description : JSON Schema Type Builder with Static Type Resolution for 
TypeScript

@sinclair/typeBox is a library that creates in-memory JSON Schema objects
that can be statically inferred as TypeScript types. The schemas produced by
this library are designed to match the static type checking rules of the
TypeScript compiler. TypeBox allows one to create a unified type that can be
both statically asserted by the TypeScript compiler and runtime asserted
using standard JSON Schema validation.

@sinclair/typeBox can be used as a simple tool to build up complex schemas or
integrated into RPC or REST services to help validate JSON data received over
the wire. TypeBox does not provide any JSON schema validation. Please use
libraries such as AJV to validate schemas built with this library.

node-sinclair-typebox is a new dependency of jest and will be maintained
under JS Team umbrella

Bug#1010275: ITP: rust-bls-dkg -- BLS DKG mechanism

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-devel@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-bls-dkg
  Version : 0.9.2
  Upstream Author : MaidSafe.net limited
* URL : https://github.com/maidsafe/bls_dkg
* License : BSD-3-clause or Expat
  Programming Lang: Rust
  Description : BLS DKG mechanism

 BLS DKG is an implementation of a BLS DKG mechanism,
 requiring signing key, encryption key and SocketAddr of participants.
 .
 A BLS digital signature - also known as Boneh–Lynn–Shacham (BLS) -
 is cryptographic signature scheme
 which allows a user to verify that a signer is authentic.
 .
 Distributed key generation (DKG)
 is a cryptographic process in which multiple parties contribute
 to the calculation of a shared public and private key set.

This package is needed for ITP package safe-network.
It will be maintained in the collaborative debian section of salsa,
here: https://salsa.debian.org/debian/rust-bls-dkg

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmJpXpQACgkQLHwxRsGg
ASH+OQ//X7Z6gpOeCVdtXMK5j4kfdRJ4tISHrGfgvE5JirguoHUndZ9vvO/+9/r4
sZiLc2zwX0OFlphV+ldVfT1JQ23Vi2EUUKuUqE8jDNp7sewMDVOx/lqY/HIyAFuF
c8KgBox8bAQ79t0Qms3MBGNNeZa30JiTGNskLTi4r0T7c3nKi9pVEpqWgkjhsi0g
ri2RriRFf66vInl5Bs1+8tBpI/Quajl/rO91B/pwIK3Kb9pnfj15MWPZhOM8agbo
IzbqhEOO8kE44Vc0cVrV/8v6qjXmUHjO57jn9mht9fA8OluNZKYrVEr85PsqQSwT
Gq0iE3a9XHwJJ1ROozBMjmcEMWYb8Vb+QZwap1yU6boMg0NOvqODrA00zyVsicMa
a60pXfKC850xpTUWE+eS5fZf9KlGehrBpJpl0DeRpIoxATd93ZtaITvDlwai0LUW
I6a1L4hvnOQJcXfAoGQzadtcZrssPBJF/ftY2nxpUh0S7LtszjNbzIUROI5jBZVw
cfrOg8xaVTNMQ+qM3TbawV1gHutIcWxdTL84Nq3X8lA1WWyXaOqIshSBIwaaYvR0
0pIaPjNO+YSXQ/jm93etJ2mRAL1aI4IkKjTbhXLPp3nkcKqs68UdA96gOVEkM/O5
+vJbzpHJrSpOIythI0RIXu7rduVfIl2rAWoxcR/O6cV7x4/W0u0=
=7Zvw
-END PGP SIGNATURE-

Advice for package needing stuff installed in /srv (node-shiny-server)

[Nilesh Patra]

Hi All,

I recently completed the packaging of node-shiny-server, uploaded to NEW and
it is there in the archive now (exp suite)

The default/expected behaviour just after package install is that as soon
as the user starts it and visits (talking about local setup here) 
localhost: they should be
seeing a welcome page.

But, the welcome page config 
(https://github.com/rstudio/shiny-server/tree/master/samples)
need to be stored in /srv/shiny-server for this welcome display to happen.
Now, I think we as a distribution are not supposed to install anything to /srv 
as they are reserved
explicitly for sys admins. I get a big fat lintian error if I even attempt to 
do that.

Without installing the welcome template to /srv/shiny-server, the user would 
get a kind
of warning message when they visit localhost and that might scare them away.
And hence, I need help/opinions to decide what should be done here.

(Note that I do not want to patch code to change the default behaviour here.)

Any ideas?

Regards,
Nilesh


signature.asc
Description: PGP signature

Re: Advice for package needing stuff installed in /srv (node-shiny-server)

[Jonas Smedegaard]

Quoting Nilesh Patra (2022-04-27 18:10:29)
> But, the welcome page config 
> (https://github.com/rstudio/shiny-server/tree/master/samples) need to 
> be stored in /srv/shiny-server for this welcome display to happen.

The path indicates that it is sample code - so I would suggest to simply 
install it as such.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Advice for package needing stuff installed in /srv (node-shiny-server)

[Wookey]

On 2022-04-27 21:40 +0530, Nilesh Patra wrote:
> Hi All,
> 
> But, the welcome page config 
> (https://github.com/rstudio/shiny-server/tree/master/samples)
> need to be stored in /srv/shiny-server for this welcome display to happen.
> 
> (Note that I do not want to patch code to change the default behaviour here.)

Why not? This is what distro packages do - make sure things are installed in 
sensible places.

And patching a path is nice and simple (although you might also have to patch 
some docs to match).

I'm not sure what the right path is. The default webserver path in debian
has been /var/www/html/ for decades so I'd use that, but you might
have reasons to make it /var/www/shiny-server instead if you want
shiny-server to be co-installable with other web-servers, and serve different 
stuff?

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: Advice for package needing stuff installed in /srv (node-shiny-server)

[Nilesh Patra]

On Wed, Apr 27, 2022 at 06:10:37PM +0100, Wookey wrote:
> On 2022-04-27 21:40 +0530, Nilesh Patra wrote:
> > Hi All,
> > 
> > But, the welcome page config 
> > (https://github.com/rstudio/shiny-server/tree/master/samples)
> > need to be stored in /srv/shiny-server for this welcome display to happen.
> > 
> > (Note that I do not want to patch code to change the default behaviour 
> > here.)
> 
> Why not? This is what distro packages do - make sure things are installed in 
> sensible places.
> 
> And patching a path is nice and simple (although you might also have to patch 
> some docs to match).

No, sorry - that'd be a bit too much delta here, meaning shiny-server would be
able to serve from two loc (I do not want that)
As a distribution I do not want to be doing
things completely orthogonal from the way upstream does things.
Not to mention that derivatives would inherit directly.

Atleast this level of effort does not seem justified for just a welcome page.

> I'm not sure what the right path is. The default webserver path in debian
> has been /var/www/html/ for decades so I'd use that, but you might
> have reasons to make it /var/www/shiny-server instead if you want
> shiny-server to be co-installable with other web-servers, and serve different 
> stuff?

Yeah that makes sense but again, same reason as I gave above. Maybe we (me and 
people in CC)
could ask upstream if they are willing to support something like this at their 
end as well.

Regards,
Nilesh


signature.asc
Description: PGP signature

Re: Advice for package needing stuff installed in /srv (node-shiny-server)

[Jonas Smedegaard]

Quoting Nilesh Patra (2022-04-27 19:17:21)
> On Wed, Apr 27, 2022 at 06:10:37PM +0100, Wookey wrote:
> > On 2022-04-27 21:40 +0530, Nilesh Patra wrote:
> > > But, the welcome page config 
> > > (https://github.com/rstudio/shiny-server/tree/master/samples) need 
> > > to be stored in /srv/shiny-server for this welcome display to 
> > > happen.
> > > 
> > > (Note that I do not want to patch code to change the default 
> > > behaviour here.)
> > 
> > Why not? This is what distro packages do - make sure things are 
> > installed in sensible places.
> > 
> > And patching a path is nice and simple (although you might also have 
> > to patch some docs to match).
> 
> No, sorry - that'd be a bit too much delta here, meaning shiny-server 
> would be able to serve from two loc (I do not want that) As a 
> distribution I do not want to be doing things completely orthogonal 
> from the way upstream does things.

Following FHS 3.0 is required by Debian Policy, and it says that "no 
program should rely on a specific subdirectory structure of /srv 
existing or data necessarily being stored in /srv".

So if I understand the situation correctly, leaving the package to 
depend on filesystem path /srv/shiny-server is a violation of Debian 
Policy and needs to be fixed, either by avoiding that code (installing 
it only as example files) or patching, or convincing upstream to change 
default path.

 - Jonas

https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#srvDataForServicesProvidedBySystem

https://www.debian.org/doc/debian-policy/ch-opersys.html#file-system-structure

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Advice for package needing stuff installed in /srv (node-shiny-server)

[Nilesh Patra]

On Wed, Apr 27, 2022 at 07:42:29PM +0200, Jonas Smedegaard wrote:
> Following FHS 3.0 is required by Debian Policy, and it says that "no 
> program should rely on a specific subdirectory structure of /srv 
> existing or data necessarily being stored in /srv".
> So if I understand the situation correctly, leaving the package to 
> depend on filesystem path /srv/shiny-server is a violation of Debian 
> Policy and needs to be fixed,

This was the whole point of my email, and it is the reason I started
this email thread in the first place.

I would have gone with installing it in /srv w/o seeking advice if it were
not a violation.

> either by avoiding that code (installing 
> it only as example files) or patching, or convincing upstream to change 
> default path.

Yes, this was discussed in just the previous conversation (w/ me and wookey)
I am looking for more opinions.

Essentially if someone has a techincal way/solution to bypass this; or if 
someone on the list
has had experience of working on a package that had similar reqs as 
shiny-server, it'd be nice to
know what they did for their package.

Best, Nilesh


signature.asc
Description: PGP signature

Re: Advice for package needing stuff installed in /srv (node-shiny-server)

[Richard Laager]

On 4/27/22 12:57, Nilesh Patra wrote:

I am looking for more opinions.


Patch every instance of /srv/shiny-server to /var/lib/shiny-server. The 
admin can customize from there.


--
Richard


OpenPGP_signature
Description: OpenPGP digital signature

Re: Advice for package needing stuff installed in /srv (node-shiny-server)

[Russ Allbery]

Richard Laager  writes:
> On 4/27/22 12:57, Nilesh Patra wrote:

>> I am looking for more opinions.

> Patch every instance of /srv/shiny-server to /var/lib/shiny-server. The
> admin can customize from there.

A possibly even better option would be for it to take the web root as a
command-line or configuration argument.  It's weird for that sort of
configuration parameter, which administrators are going to want to
customize, to be hard-coded into the package (and for me it raises
questions about its general code quality).

-- 
Russ Allbery (r...@debian.org)  

Re: Advice for package needing stuff installed in /srv (node-shiny-server)

[Ryan Kavanagh]

On Wed, Apr 27, 2022 at 11:27:43PM +0530, Nilesh Patra wrote:
> Essentially if someone has a techincal way/solution to bypass this; or
> if someone on the list has had experience of working on a package that
> had similar reqs as shiny-server, it'd be nice to know what they did
> for their package.

gophernicus had a similar issue. By default, it wanted to serve files
out of /var/gopher, but FHS §5.1 states

Applications must generally not add directories to the top level of
/var. Such directories should only be added if they have some
system-wide implication, and in consultation with the FHS mailing
list.

Instead, gophernicus in Debian serves from /srv/gopher by default to
comply with FHS §3.17.1. The gophernicus package does not create this
directory. Instead, I just documented the issue in README.Debian [0],
and included the default gophermap as an examples file.

If there's a better solution, I'd be happy to hear it.

Best,
Ryan

[0] 
https://salsa.debian.org/debian/gophernicus/-/blob/debian/sid/debian/README.Debian

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Re: Advice for package needing stuff installed in /srv (node-shiny-server)

[Ryan Kavanagh]

On Wed, Apr 27, 2022 at 01:15:04PM -0500, Richard Laager wrote:
> Patch every instance of /srv/shiny-server to /var/lib/shiny-server.
> The admin can customize from there.

From FHS §5.8.1,

This hierarchy holds state information pertaining to an application
or the system. State information is data that programs modify while
they run, and that pertains to one specific host. Users must never
need to modify files in /var/lib to configure a package's operation,
and the specific file hierarchy used to store the data must not be
exposed to regular users.

So, I think this suggestion of storing shiny-server (presumably
modifyable) configurations and served data in /var/lib/shiny-server
would violate policy.

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Re: Advice for package needing stuff installed in /srv (node-shiny-server)

[Russ Allbery]

Ryan Kavanagh  writes:

> From FHS §5.8.1,

> This hierarchy holds state information pertaining to an application
> or the system. State information is data that programs modify while
> they run, and that pertains to one specific host. Users must never
> need to modify files in /var/lib to configure a package's operation,
> and the specific file hierarchy used to store the data must not be
> exposed to regular users.

> So, I think this suggestion of storing shiny-server (presumably
> modifyable) configurations and served data in /var/lib/shiny-server
> would violate policy.

I would expect a workflow similar to that of the Apache packages.  The
default home page is a static file shipped with the package in /var, but
one of the first things that any administrator does after installing the
package is point it at a different docroot that suits their local file
system layout.

That avoids all of these problems, since there is no need to modify the
static home page in order to make the package work.  (Although the
administrator can choose to do so if they want.  I sometimes use /var to
hold various configuration things on my systems.  The actions of the local
administrator are outside the scope of the FHS, which only constrains
distributions.  This is why we use /var rather than /usr, so that
administrators can choose to just use /var if they feel like it without
running into problems with, for example, a read-only /usr.)

This issue comes up occasionally with different packages and we've never
come up with a great solution beyond making it configurable at install
(either via explicit documentation or via a debconf prompt).  It's a bit
of a gap in the FHS, in my opinion, but I'm not sure it's worth developing
local policy to close the gap by, for instance, introducing a new
top-level directory for default docroots for various services (I know of
web, gopher, and tftp with this issue).

We do try to hold the line on not installing files in /srv and not
requiring any specific layout of /srv because the FHS is pretty explicit
that the choice of directory layout in /srv is entirely up to the local
administrator and distributions should not be messing with it.

-- 
Russ Allbery (r...@debian.org)  

Re: Advice for package needing stuff installed in /srv (node-shiny-server)

[Philip Rinn]

Hi Nilesh,

On 2022-04-27 21:40 +0530, Nilesh Patra wrote:

But, the welcome page config 
(https://github.com/rstudio/shiny-server/tree/master/samples)
need to be stored in /srv/shiny-server for this welcome display to happen.


Why, you can adjust the path via a config variable, see 
https://github.com/rstudio/shiny-server/blob/master/config/default.config#L12.

How about just changing that default config and point it to 
/usr/share/shiny-server/samples or wherever you install the sample files too?
Or do I miss something here?

Best
Philip


OpenPGP_signature
Description: OpenPGP digital signature

Re: Advice for package needing stuff installed in /srv (node-shiny-server)

[Eric Brown]

Thank you all for your advice. I have been helping out to get this
packaged. I agree with Nilesh but am chiming in, but I apologize if I
am just repeated what is already clear.

/srv/shiny-server is upstream's default location for files to serve.
It starts out with the sample files but the user replaces those with
their own. The sample files start there and provide the user proof
that the server is working and an explanation on how to replace the
files.

The server directory is easily changed by modifying the config file to
whatever is desired. So it is not essential to host here, just the
default. Everything would still work if it were another directory
specified in config.

The issue is that the documentation, samples and all of the upstream
online documentation, e.g.
https://support.rstudio.com/hc/en-us/articles/219002337-Shiny-Server-Quick-Start-Host-a-directory-of-applications
(or on third party sites like Stack Overflow), refer to
/srv/shiny-server as the default location for hosting. I doubt
upstream would want to change all of that without a strong reason.

>From a user's perspective it would be much clearer if Debian could do
the same, in my opinion, so all of this existing and distributed
documentation and support still applies to new users of the Debian
version. Is there a technical solution to enable this, e.g. post
installation, that satisfies Debian's requirements?

Many thanks,
Eric

On Wed, Apr 27, 2022 at 1:57 PM Nilesh Patra  wrote:
>
> On Wed, Apr 27, 2022 at 07:42:29PM +0200, Jonas Smedegaard wrote:
> > Following FHS 3.0 is required by Debian Policy, and it says that "no
> > program should rely on a specific subdirectory structure of /srv
> > existing or data necessarily being stored in /srv".
> > So if I understand the situation correctly, leaving the package to
> > depend on filesystem path /srv/shiny-server is a violation of Debian
> > Policy and needs to be fixed,
>
> This was the whole point of my email, and it is the reason I started
> this email thread in the first place.
>
> I would have gone with installing it in /srv w/o seeking advice if it were
> not a violation.
>
> > either by avoiding that code (installing
> > it only as example files) or patching, or convincing upstream to change
> > default path.
>
> Yes, this was discussed in just the previous conversation (w/ me and wookey)
> I am looking for more opinions.
>
> Essentially if someone has a techincal way/solution to bypass this; or if 
> someone on the list
> has had experience of working on a package that had similar reqs as 
> shiny-server, it'd be nice to
> know what they did for their package.
>
> Best, Nilesh



-- 
Eric Brown MD MSc FRCPC
For encryption, OpenPGP public key available on request.

Re: Advice for package needing stuff installed in /srv (node-shiny-server)

[Russ Allbery]

Eric Brown  writes:

> The issue is that the documentation, samples and all of the upstream
> online documentation, e.g.
> https://support.rstudio.com/hc/en-us/articles/219002337-Shiny-Server-Quick-Start-Host-a-directory-of-applications
> (or on third party sites like Stack Overflow), refer to
> /srv/shiny-server as the default location for hosting. I doubt
> upstream would want to change all of that without a strong reason.

> From a user's perspective it would be much clearer if Debian could do
> the same, in my opinion, so all of this existing and distributed
> documentation and support still applies to new users of the Debian
> version. Is there a technical solution to enable this, e.g. post
> installation, that satisfies Debian's requirements?

Not really.  This is the same issue that we've had before with other
things.  Given current Policy, you have to choose between pointing at a
file installed with the package or defaulting to the upstream /srv
location without there being a file there.

It's not a great situation, and there was a long discussion a while back
about how to address the same issue with tftp services that I think didn't
arrive at a clear conclusion.

-- 
Russ Allbery (r...@debian.org)  

Re: Advice for package needing stuff installed in /srv (node-shiny-server)

[Eric Brown]

Thank you for the explanation, and thanks for the history and pointer 
towards tftp. Looks like you remembered correctly 
(https://lists.debian.org/debian-devel/2020/02/msg00197.html). I 
installed tftpd-ahp. Interestingly, after all that discussion, it still 
does create a directory /srv/tftp which is its default served directory, 
like the upstream shiny-server behaviour.

Best,
Eric

feedback for NEW packages: switch to using the BTS?

[Paul Wise]

Hi all,

During the discussions about NEW on debian-devel in recent times, I had
the idea that instead of the current mechanism of sending REJECT mails,
Debian could switch to using the BTS for most feedback on NEW packages.

This means that most discussion about NEW packages would become public,
but of course the ftpmasters could opt to send private mail instead if
in some cases if there were sensitive issues to be discussed.

The ftpmasters could simply file severity serious bug reports against
NEW packages that have issues blocking their entry into Debian. When
there are minor issues noticed at the same time, then file bugs of a
lower severity. Only when a NEW package has not had its serious bugs
fixed in a long time would an eventual removal and REJECT mail happen,
perhaps after a few months of zero action on the bug reports.

The changes that are needed to make this happen include:

The community needs to decide that this change is a good idea and be
willing to recieve most feedback on their work in public.

The BTS and ftpmaster teams need to agree with this change.
One BTS admin said this is feasible in principle and one of the
ftpmasters seemed to like the idea when I mentioned it on IRC.

Where the bug mail should go to needs to be decided on. Personally I'm
thinking the person who did the upload plus the Maintainer field.

The people doing processing of NEW packages need to be willing to file
bug reports against them where necessary.

dak needs to export debian/changelog version lists for NEW packages.

debbugs needs to import packages/versions from the new.822 file:

https://ftp-master.debian.org/new.822

dak needs to link to the BTS from new.822 and the NEW packages info.

https://ftp-master.debian.org/new.html

The technical work needed here is minimal, so if there are no other
volunteers to do that work, then I would be willing to do it. I have
experience with Perl/Python but only a small amount of experience with
working on the debbugs and dak codebases.

Thoughts welcome, especially from those who don't like this idea.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: shim-signed

[Tollef Fog Heen]

]] Hanno 'Rince' Wagner 

> Hi everbody,
> 
> On Sun, 24 Apr 2022, Tollef Fog Heen wrote:
> 
> > I don't think we have docs for running with a different root of trust
> > than MS'. To be honest, I'm not sure we even _should_ have a lot of docs
> > around it, since the general brittleness of the boot process, UEFI and
> > friends might very well lead to more systems being broken when people
> > discover the docs and run with the instructions without understanding
> > the implications.
> 
> I am a very firm believer of giving people as much information as
> possible while being responsible. Meaning, that I would love to have
> that documentation - including a big warning sign which sais "if you
> follow this path, you may brick your machine and this is your problem,
> not ours". If someone is interested to learn _how_ the security is
> done and implemented, why should this be unavailable?

Sadly, warnings generally don't work because people will ignore them and
break their systems and then blame the people writing the
documentation, causing load and grief on people were trying to be
helpful by writing the docs.

I don't think we should invest a lot into writing the docs required
because we can use that effort elsewhere.  Documentation requires
maintenance, just like everything else and if it's rarely used, we get
little value out of that effort.  If somebody is very eager to write and
maintain that documentation over time, by all means, but we haven't seen
anyone step up to do so.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: shim-signed

[Tollef Fog Heen]

]] The Wanderer 

> I can't speak to how big of an advantage A is, but B seems to me to be
> pretty important.

It's a manual process that includes poking around in MS' partner portal,
USB HSMs stored in a safe place and rebooting to Windows, then checking
back days (and sometimes weeks) later to download the result.  It's not
something we would want to do for anything fast-moving.

> If that understanding is not correct, I'd be interested to learn what
> the actual point of having the shim is.

Part of it is also that Microsoft is not going to sign GPL-ed code,
certainly not GPLv3.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Advice for package needing stuff installed in /srv (node-shiny-server)

[Andreas Tille]

Am Wed, Apr 27, 2022 at 11:39:45AM -0700 schrieb Russ Allbery:
> 
> We do try to hold the line on not installing files in /srv and not
> requiring any specific layout of /srv because the FHS is pretty explicit
> that the choice of directory layout in /srv is entirely up to the local
> administrator and distributions should not be messing with it.

I wonder whether we can simply use /var (not sure what might be best out
of /var/www/shiny-server or /var/lib/shiny-server or ???) for the "real"
installation and use a symlink to /srv/shiny-server (which can be even
set via debconf or in prominent documentation).  This puts the files in
the right place per FHS but does not lead to big surprises at user side.

Kind regards

   Andreas.

-- 
http://fam-tille.de