Re: [HEADSUP] Deprecation of the ftp support in pkg

2022-01-23 Thread Li-Wen Hsu
On Sun, Jan 23, 2022 at 5:30 AM tech-lists  wrote:
>
> On Thu, Jan 20, 2022 at 03:25:19PM +0100, Baptiste Daroussin wrote:
> >Hello everyone,
> >
> >We plan to remove the support for fetching packages over ftp for the next
> >releases of pkg (probably 1.18) if you have a strong reason to use ftp which
> >cannot be fixed by switching to any other supported protocols like ssh or 
> >http,
> >please do share.
>
> Hi,
>
> Some places (jurastictions or companies) might not allow ssh.
> Others might not allow https.
>
> With variety there is choice. Is ftp a great overhead?

If this is due to security considerations, I don't think a place
disallowing ssh and https would allow plain ftp.

If it is because they don't like encrypted connections, I suggest
using plain http in this case.

Best,
Li-Wen



Re: [HEADSUP] Deprecation of the ftp support in pkg

2022-01-23 Thread Mehmet Erol Sanliturk
On Sun, Jan 23, 2022 at 12:32 PM Li-Wen Hsu  wrote:

> On Sun, Jan 23, 2022 at 5:30 AM tech-lists  wrote:
> >
> > On Thu, Jan 20, 2022 at 03:25:19PM +0100, Baptiste Daroussin wrote:
> > >Hello everyone,
> > >
> > >We plan to remove the support for fetching packages over ftp for the
> next
> > >releases of pkg (probably 1.18) if you have a strong reason to use ftp
> which
> > >cannot be fixed by switching to any other supported protocols like ssh
> or http,
> > >please do share.
> >
> > Hi,
> >
> > Some places (jurastictions or companies) might not allow ssh.
> > Others might not allow https.
> >
> > With variety there is choice. Is ftp a great overhead?
>
> If this is due to security considerations, I don't think a place
> disallowing ssh and https would allow plain ftp.
>
> If it is because they don't like encrypted connections, I suggest
> using plain http in this case.
>
> Best,
> Li-Wen
>
>

At present , there are many ftp sites in service .
I do not know ssh ( because I never used it ) .

Now Firefox is not LIKING to connect to ftp sites . I am using Qupzilla (
in Linux )
when I click an ftp site in Firefox , i.e.  Firefox is forking Qupzilla for
that ftp site .

Also there is  Filezilla for ftp sites , among other possible alternatives .


My question ( which it may be wrong due to my lack of knowledge ) :


Can we use   ssh  like  Qupzilla or Filezilla on existing ftp sites or
can   ssh   be a sufficiently powerful  alternative  to Qupzilla or
Filezilla  ?


With my best wishes ,


Mehmet Erol Sanliturk


Re: [HEADSUP] Deprecation of the ftp support in pkg

2022-01-23 Thread tech-lists

On Sun, Jan 23, 2022 at 05:32:26PM +0800, Li-Wen Hsu wrote:


If this is due to security considerations, I don't think a place
disallowing ssh and https would allow plain ftp.


Some places either might not have or might not allow egress.
Some networks are closed at install time. An ftp server 
on a LAN is quick and easy and is in base.



If it is because they don't like encrypted connections, I suggest
using plain http in this case.


Some places proxy port 80/443 and there may be no way for the end
user to get around that. They might not proxy ftp outbound.
--
J.


signature.asc
Description: PGP signature


Re: [HEADSUP] Deprecation of the ftp support in pkg

2022-01-23 Thread Jose Quinteiro
On 1/23/22 08:47, tech-lists wrote:
> On Sun, Jan 23, 2022 at 05:32:26PM +0800, Li-Wen Hsu wrote:
>>
>> If this is due to security considerations, I don't think a place
>> disallowing ssh and https would allow plain ftp.
> 
> Some places either might not have or might not allow egress.
> Some networks are closed at install time. An ftp server on a LAN is
> quick and easy and is in base.
> 
>> If it is because they don't like encrypted connections, I suggest
>> using plain http in this case.
> 
> Some places proxy port 80/443 and there may be no way for the end
> user to get around that. They might not proxy ftp outbound.

You can run HTTP on a non-standard port. For example, 8080 is commonly
used. As an added bonus, this means that the HTTP server need not run as
root.

Thanks,
Jose.



Re: [HEADSUP] Deprecation of the ftp support in pkg

2022-01-23 Thread tech-lists

On Thu, Jan 20, 2022 at 03:25:19PM +0100, Baptiste Daroussin wrote:

Hello everyone,

We plan to remove the support for fetching packages over ftp for the next
releases of pkg (probably 1.18) if you have a strong reason to use ftp which
cannot be fixed by switching to any other supported protocols like ssh or http,
please do share.


ssh & https are slower through low-powered devices than unencrypted
protocols. 

It may be easy enough for me to change protocols but that might not 
be the same for everyone. Why remove a still widely-used protocol 
that an update method (i.e. pkg) uses?

--
J.


signature.asc
Description: PGP signature


Re: [HEADSUP] Deprecation of the ftp support in pkg

2022-01-23 Thread tech-lists

On Sun, Jan 23, 2022 at 08:55:09AM -0800, Jose Quinteiro wrote:


You can run HTTP on a non-standard port. For example, 8080 is commonly
used. As an added bonus, this means that the HTTP server need not run as
root.


Unless I'm mistaken, there is no web server in base. There is though, an 
ftp server.

--
J.


signature.asc
Description: PGP signature


Re: [HEADSUP] Deprecation of the ftp support in pkg

2022-01-23 Thread Jose Quinteiro
On 1/23/22 09:06, tech-lists wrote:
> On Sun, Jan 23, 2022 at 08:55:09AM -0800, Jose Quinteiro wrote:
> 
>> You can run HTTP on a non-standard port. For example, 8080 is commonly
>> used. As an added bonus, this means that the HTTP server need not run as
>> root.
> 
> Unless I'm mistaken, there is no web server in base. There is though, an
> ftp server.

Touche. I wouldn't mind having Thttpd in base.
https://www.acme.com/software/thttpd/

Thanks,
Jose



Re: [HEADSUP] Deprecation of the ftp support in pkg

2022-01-23 Thread Patrick M. Hausen
Hi all,

I did not really have an opinion on this, since we never used FTP,
but I was a bit surprised by the suggestion to use SSH instead.

It never occurred to us that anything but HTTP(S) was possible.
We simply run Nginx in a jail serving the packages that Poudriere
produces for us. Setup time/effort: 5 minutes.

Now after this comment:

> Am 22.01.2022 um 09:35 schrieb Chris :
> I find it's less "housekeeping" to use ftp(1) setup through inetd(8) for pkg 
> repos, than
> via ssh.

I understand the appeal of FTP. 
Maybe this discussion is focusing on the wrong topic. Perhaps
we should consider including a light weight way to serve HTTP(S)
in base? Like Lighttpd, which as far as I know comes with a BSD
3-clause equivalent license.

But then the general tendency has been to remove network services
from base rather than introduce them. Like e.g. BIND.

So I really have no idea what the general opinion is, just wanted
to throw in that IMHO HTTPS is the best protocol to the task and
if some way to serve that could be included in base, I for one would
appreciate that.

OTOH Chris, what's keeping you from installing a web server just
serving static files?

Kind regards,
Patrick
-- 
punkt.de GmbH
Patrick M. Hausen
.infrastructure

Kaiserallee 13a
76133 Karlsruhe

Tel. +49 721 9109500

https://infrastructure.punkt.de
i...@punkt.de

AG Mannheim 108285
Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein




Re: [HEADSUP] Deprecation of the ftp support in pkg

2022-01-23 Thread Stefan Esser
Am 23.01.22 um 18:12 schrieb Jose Quinteiro:
> On 1/23/22 09:06, tech-lists wrote:
>> On Sun, Jan 23, 2022 at 08:55:09AM -0800, Jose Quinteiro wrote:
>>
>>> You can run HTTP on a non-standard port. For example, 8080 is commonly
>>> used. As an added bonus, this means that the HTTP server need not run as
>>> root.
>>
>> Unless I'm mistaken, there is no web server in base. There is though, an
>> ftp server.
> 
> Touche. I wouldn't mind having Thttpd in base.
> https://www.acme.com/software/thttpd/

An interesting idea, we have it as a port in www/thttpd.

While we generally rather move base components that are not
generally required to ports, this might be a case where it
makes sense to replace one base system component by another
one currently only available as a port ...

The thttpd binary is smaller than the ftpd currently in base,
and it might make sense to replace ftpd by this simple httpd:

$ size /usr/libexec/ftpd
   textdata bss dec hex filename
 10590142765984  116161   1c5c1 /usr/libexec/ftpd

$ size work/stage/usr/local/sbin/*
   textdata bss dec hex filename
   5469 656 1126237185d work/stage/usr/local/sbin/makeweb
   7453 760 1208333208d work/stage/usr/local/sbin/thtpasswd
  8118483362280   91800   16698 work/stage/usr/local/sbin/thttpd

The sources are distributed under a 2 clause BSD copyright.

Maybe having a HTTP server in base is more useful than a FTP
server, today ...

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature


Re: [HEADSUP] Deprecation of the ftp support in pkg

2022-01-23 Thread Mehmet Erol Sanliturk
On Sun, Jan 23, 2022 at 11:27 PM Stefan Esser  wrote:

> Am 23.01.22 um 18:12 schrieb Jose Quinteiro:
> > On 1/23/22 09:06, tech-lists wrote:
> >> On Sun, Jan 23, 2022 at 08:55:09AM -0800, Jose Quinteiro wrote:
> >>
> >>> You can run HTTP on a non-standard port. For example, 8080 is commonly
> >>> used. As an added bonus, this means that the HTTP server need not run
> as
> >>> root.
> >>
> >> Unless I'm mistaken, there is no web server in base. There is though, an
> >> ftp server.
> >
> > Touche. I wouldn't mind having Thttpd in base.
> > https://www.acme.com/software/thttpd/
>
> An interesting idea, we have it as a port in www/thttpd.
>
> While we generally rather move base components that are not
> generally required to ports, this might be a case where it
> makes sense to replace one base system component by another
> one currently only available as a port ...
>
> The thttpd binary is smaller than the ftpd currently in base,
> and it might make sense to replace ftpd by this simple httpd:
>
> $ size /usr/libexec/ftpd
>textdata bss dec hex filename
>  10590142765984  116161   1c5c1 /usr/libexec/ftpd
>
> $ size work/stage/usr/local/sbin/*
>textdata bss dec hex filename
>5469 656 1126237185d work/stage/usr/local/sbin/makeweb
>7453 760 1208333208d work/stage/usr/local/sbin/thtpasswd
>   8118483362280   91800   16698 work/stage/usr/local/sbin/thttpd
>
>




> The sources are distributed under a 2 clause BSD copyright.
>
>

I checked all of the sources  by downloading related compressed sources ,
by reading all of the web pages in the shown website , I could not find
any license information .

If it is possible for you , would you please supply a link to this license
information ?


Mehmet Erol Sanliturk






> Maybe having a HTTP server in base is more useful than a FTP
> server, today ...
>
> Regards, STefan
>


Re: [HEADSUP] Deprecation of the ftp support in pkg

2022-01-23 Thread Stefan Esser
Am 23.01.22 um 22:41 schrieb Mehmet Erol Sanliturk:> On Sun, Jan 23, 2022 at
11:27 PM Stefan Esser  > wrote:
> 
> Am 23.01.22 um 18:12 schrieb Jose Quinteiro:
> > On 1/23/22 09:06, tech-lists wrote:
> >> On Sun, Jan 23, 2022 at 08:55:09AM -0800, Jose Quinteiro wrote:
> >>
> >>> You can run HTTP on a non-standard port. For example, 8080 is commonly
> >>> used. As an added bonus, this means that the HTTP server need not run 
> as
> >>> root.
> >>
> >> Unless I'm mistaken, there is no web server in base. There is though, 
> an
> >> ftp server.
> >
> > Touche. I wouldn't mind having Thttpd in base.
> > https://www.acme.com/software/thttpd/ 
> 
> 
> An interesting idea, we have it as a port in www/thttpd.
> 
> While we generally rather move base components that are not
> generally required to ports, this might be a case where it
> makes sense to replace one base system component by another
> one currently only available as a port ...
> 
> The thttpd binary is smaller than the ftpd currently in base,
> and it might make sense to replace ftpd by this simple httpd:
> 
> $ size /usr/libexec/ftpd
>    text    data     bss     dec     hex filename
>  105901    4276    5984  116161   1c5c1 /usr/libexec/ftpd
> 
> $ size work/stage/usr/local/sbin/*
>    text    data     bss     dec     hex filename
>    5469     656     112    6237    185d work/stage/usr/local/sbin/makeweb
>    7453     760     120    8333    208d 
> work/stage/usr/local/sbin/thtpasswd
>   81184    8336    2280   91800   16698 work/stage/usr/local/sbin/thttpd
> 
> 
> 
> 
>  
> 
> The sources are distributed under a 2 clause BSD copyright.
> 
> 
> 
> I checked all of the sources  by downloading related compressed sources ,
> by reading all of the web pages in the shown website , I could not find
> any license information .
> 
> If it is possible for you , would you please supply a link to this license
> information ?

Each individual C source file starts with a Copyright note like this:

/* thttpd.c - tiny/turbo/throttling HTTP server
**
** Copyright © 1995,1998,1999,2000,2001,2015 by
** Jef Poskanzer . All rights reserved.
**
** Redistribution and use in source and binary forms, with or without
** modification, are permitted provided that the following conditions
** are met:
** 1. Redistributions of source code must retain the above copyright
**notice, this list of conditions and the following disclaimer.
** 2. Redistributions in binary form must reproduce the above copyright
**notice, this list of conditions and the following disclaimer in the
**documentation and/or other materials provided with the distribution.
**
** THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
** ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
** IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
** ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
** FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
** DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
** OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
** HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
** LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
** OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
** SUCH DAMAGE.
*/

The auto-configure files are under GPL, but not relevant for the resulting
binary and not required for building in the base system. The install.sh
script has a MIT license, but it is also not relevant for us.

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature


Re: [HEADSUP] Deprecation of the ftp support in pkg

2022-01-23 Thread Mark Millard
Mehmet Erol Sanliturk  wrote on
Date: Mon, 24 Jan 2022 00:41:34 +0300 :

> I checked all of the sources  by downloading related compressed sources ,
> by reading all of the web pages in the shown website , I could not find
> any license information .
> 
> If it is possible for you , would you please supply a link to this license
> information ?

Backing up to http://www.acme.com provides a link to the license for
all the ACME Labs Freeware : a link to http://www.acme.com/license.html

I'm not claiming that is the only place the license can be found,
just a place. I've not looked elsewhere.

===
Mark Millard
marklmi at yahoo.com




Re: [HEADSUP] Deprecation of the ftp support in pkg

2022-01-23 Thread Mehmet Erol Sanliturk
On Mon, Jan 24, 2022 at 3:15 AM Mark Millard  wrote:

> Mehmet Erol Sanliturk  wrote on
> Date: Mon, 24 Jan 2022 00:41:34 +0300 :
>
> > I checked all of the sources  by downloading related compressed sources ,
> > by reading all of the web pages in the shown website , I could not find
> > any license information .
> >
> > If it is possible for you , would you please supply a link to this
> license
> > information ?
>
> Backing up to http://www.acme.com provides a link to the license for
> all the ACME Labs Freeware : a link to http://www.acme.com/license.html
>
> I'm not claiming that is the only place the license can be found,
> just a place. I've not looked elsewhere.
>
> ===
> Mark Millard
> marklmi at yahoo.com



Yes , this is what I am searching and sufficient for a definite license
information :

http://www.acme.com/license.html

Thanks to you and Stefan Esser for your replies ,

Mehmet Erol Sanliturk


Re: Deprecation of the ftp support in pkg

2022-01-23 Thread Jose Quinteiro
On 1/23/22 13:12, Helge Oldach wrote:
> Stefan Esser wrote on Sun, 23 Jan 2022 21:08:30 +0100 (CET):
>> Am 23.01.22 um 18:12 schrieb Jose Quinteiro:
>>> On 1/23/22 09:06, tech-lists wrote:
 On Sun, Jan 23, 2022 at 08:55:09AM -0800, Jose Quinteiro wrote:

> You can run HTTP on a non-standard port. For example, 8080 is commonly
> used. As an added bonus, this means that the HTTP server need not run as
> root.

 Unless I'm mistaken, there is no web server in base. There is though, an
 ftp server.
>>>
>>> Touche. I wouldn't mind having Thttpd in base.
>>> https://www.acme.com/software/thttpd/
>>
>> An interesting idea, we have it as a port in www/thttpd.
> 
> Does thttpd support SSL in the meantime? I suspect that is an option people 
> would ask for instantly.
> 
It does not. This is by design. It is really meant to be as small and
simple as possible. Not unlike the Varnish no-ssl design decision.

Thanks,
Jose



Re: [HEADSUP] Deprecation of the ftp support in pkg

2022-01-23 Thread Alexander Leidinger
Quoting "Patrick M. Hausen"  (from Sun, 23 Jan 2022  
19:19:57 +0100):



Am 22.01.2022 um 09:35 schrieb Chris :
I find it's less "housekeeping" to use ftp(1) setup through  
inetd(8) for pkg repos, than

via ssh.


I understand the appeal of FTP.
Maybe this discussion is focusing on the wrong topic. Perhaps
we should consider including a light weight way to serve HTTP(S)
in base? Like Lighttpd, which as far as I know comes with a BSD
3-clause equivalent license.

But then the general tendency has been to remove network services
from base rather than introduce them. Like e.g. BIND.

So I really have no idea what the general opinion is, just wanted
to throw in that IMHO HTTPS is the best protocol to the task and
if some way to serve that could be included in base, I for one would
appreciate that.


Personally I think that a http(s) server is not needed in base, as  
long as we don't need it for something in base (and I wouldn't mind if  
ftpd would get removed from base for the same reason). Installing a  
package is easy enough (no matter if for http or ftp).


I think in this thread it was mentioned that someone didn't want to  
install 3rd party software for this. I still can't wrap my head around  
that part...:
 - we talk about a tool which is used to exclusively install 3rd  
party software (pkg)
 - this tool itself is installed like a 3rd party software  
(package/port, the system-pkg is only a bootstrap)
 - and the complete context is serving 3rd party software from a tool  
which builds 3rd party software locally (poudriere) or at least a  
downloaded subset from FreeBSD
 - poudriere is also not in the base system but installed like a 3rd  
party software
 - maintaining a list of software you are interested in (be it for  
poudriere or for automated downloads of FreeBSD packages into a local  
repo) seems more effort to me, than setting up one more 3rd party  
software for local file distribution


I wanted to propose here to include config snippeds for  
apache/nginx/thttp for such an use-case to decrease the configuration  
burden, but this seems to be already the case (at least for  
nginx/apache). I can't see within 30sec any docs about this in the  
poudriere wiki, so maybe adding a prominent pointer to it there might  
be an improvement?


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF