Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 Sep 2020 17:03:02 +0000 (UTC)
From:      Filippo Moretti <filippomore@yahoo.com>
To:        Yasuhiro KIMURA <yasu@utahime.org>
Cc:        FreeBSD Current <current@freebsd.org>
Subject:   Re: Problem compiling world amd64
Message-ID:  <1885244210.3961054.1600448582022@mail.yahoo.com>
In-Reply-To: <20200918.171951.1442109784437640368.yasu@utahime.org>
References:  <1035415533.3781447.1600415860170.ref@mail.yahoo.com> <1035415533.3781447.1600415860170@mail.yahoo.com> <20200918.171951.1442109784437640368.yasu@utahime.org>

next in thread | previous in thread | raw e-mail | index | archive | help
 Thank you very much buildworld worked properly
sincerelyFilippo

    On Friday, September 18, 2020, 10:20:58 AM GMT+2, Yasuhiro KIMURA <yasu=
@utahime.org> wrote: =20
=20
 From: Filippo Moretti <filippomore@yahoo.com>
Subject: Problem compiling world amd64
Date: Fri, 18 Sep 2020 07:57:40 +0000 (UTC)

> [filippo@sting ~]$ uname -a
> FreeBSD sting 13.0-CURRENT FreeBSD 13.0-CURRENT #11 r365578: Thu Sep 10 1=
9:38:51 CEST 2020=C2=A0=C2=A0=C2=A0=C2=A0 root@sting:/usr/obj/usr/src/amd64=
.amd64/sys/STING=C2=A0 amd64
>=20
(snip)
> --- beforedepend ---
> mkdir -p xlocale arpa;=C2=A0 for i in a.out.h assert.h elf.h limits.h nli=
st.h setjmp.h stddef.h stdbool.h string.h strings.h time.h unistd.h uuid.h;=
 do=C2=A0 ln -sf /usr/src/include/$i $i;=C2=A0 done;=C2=A0 ln -sf /usr/src/=
sys/amd64/include/stdarg.h stdarg.h;=C2=A0 ln -sf /usr/src/sys/sys/errno.h =
errno.h;=C2=A0 ln -sf /usr/src/sys/sys/stdint.h stdint.h;=C2=A0 ln -sf /usr=
/src/include/arpa/inet.h arpa/inet.h;=C2=A0 ln -sf /usr/src/include/arpa/tf=
tp.h arpa/tftp.h;=C2=A0 for i in _time.h _strings.h _string.h; do=C2=A0 [ -=
f =C2=A0xlocale/$i ] || cp /dev/null xlocale/$i;=C2=A0 done;=C2=A0 for i in=
 ctype.h fcntl.h signal.h stdio.h stdlib.h; do=C2=A0 ln -sf /usr/src/stand/=
libsa/stand.h $i;=C2=A0 done
> cp: /dev/null: Invalid argument
> *** [beforedepend] Error code 1
>=20
> make[4]: stopped in /usr/src/stand/libsa
> --- all_subdir_secure ---
> --- all_subdir_share ---
> --- all_subdir_lib ---
>=20
> The error is recurringFilippo

1. Update source tree to r365643 or later.
2. cd /usr/src/bin/cp
3. make
4. make install
5. cd /usr/src
6. make buildworld

---
Yasuhiro KIMURA
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
 =20
From owner-freebsd-current@freebsd.org  Fri Sep 18 17:38:35 2020
Return-Path: <owner-freebsd-current@freebsd.org>
Delivered-To: freebsd-current@mailman.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
 by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3D18B3E8773
 for <freebsd-current@mailman.nyi.freebsd.org>;
 Fri, 18 Sep 2020 17:38:35 +0000 (UTC)
 (envelope-from darkfiberiru@gmail.com)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com
 [IPv6:2a00:1450:4864:20::236])
 (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
 client-signature RSA-PSS (2048 bits) client-digest SHA256)
 (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK))
 by mx1.freebsd.org (Postfix) with ESMTPS id 4BtLfL3DVFz3bKg;
 Fri, 18 Sep 2020 17:38:34 +0000 (UTC)
 (envelope-from darkfiberiru@gmail.com)
Received: by mail-lj1-x236.google.com with SMTP id a15so5763905ljk.2;
 Fri, 18 Sep 2020 10:38:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=aN7OeZ2EaBZhlF6IYxTIQOnUh5TWuMTFj6arESs7LZc=;
 b=STxzhG8upsfSj6assbkFU69Hk6ZcrUt9bQVF8Ge5Fwtys2lEH2yQA9m36tgbr0wycR
 s0QTIahiv/kUtmkSx47agGIEJDPhiQ8Rpuati5WA/qCZo4rE10uTLpM+pihrAD1cSb2f
 tVB0zWfr7iB2x0aMsHKeWMI+r5u+TjLwqCrpOQiqBFz8sOKLr7H2xWa6qEf2vBaeRS9+
 FVmlwpnz9RMaLsmWCocFx+kvCCS/D0NR1t7jpte3GrmyJANEEqR7EIKoRS9zZ4Bw+4Tb
 QP0IuZdxL0+RKRGculZIDOVWuUxLZLrtdUv53vJ+nKO9rkGL5xnctfDxhwJslAltaNac
 qtTA==
X-Gm-Message-State: AOAM530geW7fARqSJlEbLAjhGrnLga8MRhxJVF59uHVj/0y+5x5tLsJG
 k2cpcuX01jRyeTqyt67M6J2R99TS/2IPyA/NtKYkJn3XYj1yyA==
X-Google-Smtp-Source: ABdhPJz1aCSOE6eyQyoBmxa0FvH/y33XVavNixRReOPboBt3/0SfIHNCym6aHajHb4HabjnnKHcQrf057SYI82/yGlk=
X-Received: by 2002:a2e:a418:: with SMTP id p24mr12164698ljn.205.1600450711394; 
 Fri, 18 Sep 2020 10:38:31 -0700 (PDT)
MIME-Version: 1.0
References: <CAPyFy2BHki84KuzP94AqTLk7v9FTAnLP-sa4HaFLq0kdxt0dEQ@mail.gmail.com>
 <202009171404.08HE4fZj007939@slippy.cwsent.com>
 <CALH631n=MEvoS+3qOo9nM6-VXYW85jVxv1ih1w=7kfW6E0feag@mail.gmail.com>
 <4d2c3d9dd633ed9a264cf3675dcbb4386f11ada3.camel@freebsd.org>
 <20200917194941.GY4213@funkthat.com>
 <0ab6a75e6b821058a2b939447a8e499196ec2388.camel@freebsd.org>
In-Reply-To: <0ab6a75e6b821058a2b939447a8e499196ec2388.camel@freebsd.org>
From: Nick Wolff <darkfiberiru@gmail.com>
Date: Fri, 18 Sep 2020 13:38:18 -0400
Message-ID: <CACxAneCG_4pSgGwhnBgsNBQMT3Cs02LBH2GHpehCFp2XOveigQ@mail.gmail.com>
Subject: Re: Deprecating ftpd in the FreeBSD base system?
To: Ian Lepore <ian@freebsd.org>
Cc: John-Mark Gurney <jmg@funkthat.com>,
 FreeBSD Current <freebsd-current@freebsd.org>
X-Rspamd-Queue-Id: 4BtLfL3DVFz3bKg
X-Spamd-Bar: --
X-Spamd-Result: default: False [-2.10 / 15.00]; RCVD_TLS_ALL(0.00)[];
 ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025];
 NEURAL_HAM_MEDIUM(-1.03)[-1.029]; FROM_HAS_DN(0.00)[];
 RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com];
 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
 NEURAL_HAM_LONG(-1.04)[-1.041]; TO_MATCH_ENVRCPT_SOME(0.00)[];
 TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+];
 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::236:from];
 NEURAL_HAM_SHORT(-0.03)[-0.029]; FROM_EQ_ENVFROM(0.00)[];
 MIME_TRACE(0.00)[0:+,1:+,2:~];
 FREEMAIL_ENVFROM(0.00)[gmail.com];
 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
 SUBJECT_ENDS_QUESTION(1.00)[];
 MAILMAN_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]
Content-Type: text/plain; charset="UTF-8"
X-Content-Filtered-By: Mailman/MimeDel 2.1.33
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.33
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
 <freebsd-current.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-current>, 
 <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>;
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
 <mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Sep 2020 17:38:35 -0000

On Thu, Sep 17, 2020 at 3:54 PM Ian Lepore <ian@freebsd.org> wrote:

> On Thu, 2020-09-17 at 12:49 -0700, John-Mark Gurney wrote:
> > Ian Lepore wrote this message on Thu, Sep 17, 2020 at 09:01 -0600:
> > > On Thu, 2020-09-17 at 18:43 +0400, Gleb Popov wrote:
> > > > On Thu, Sep 17, 2020 at 6:05 PM Cy Schubert <
> > > > Cy.Schubert@cschubert.com>
> > > > wrote:
> > > >
> > > > > I've been advocating removing FTP (and HTTP) from libfetch as
> > > > > well.
> > > > > People
> > > > > should be using HTTPS only.
> > > > >
> > > >
> > > > Isn't this a bit too much? I often find myself in need to
> > > > download
> > > > something starting with "http://" or "ftp://" and use fetch for
> > > > this.
> > >
> > > Indeed, we have products which rely on this ability in libfetch and
> > > we
> > > have to keep supporting them for many many years to come.
> > >
> > > I hate it when someone imperiously declares [For security reasons]
> > > "People should/shouldn't be using ______".  You have no idea what
> > > the
> > > context is, and thus no ability to declare what should or shouldn't
> > > be
> > > used in that context.  For example, two embedded systems talking to
> > > each other over a point to point link within a sealed device are
> > > not
> > > concerned about man in the middle attacks or other modern internet
> > > threats.
> >
> > And I really dislike when people want to make sure that their unique
> > case that less than a percent of people would every hit blocks the
> > security improvements for the majority of people...
> >
> > I've given up on a number of security improvements in FreeBSD because
> > of this attitude...
> >
>
> Good.  Because what you call "improvements" I would probably call
> "Imposing policy rather than providing tools."
>
> I've don't complain about making defaults the safest choices available.
> I complain about removing options completely because they're unsafe in
> some circumstances according to some people.
>
> -- Ian
>
>
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
>

  Even making defaults the "safest choice" I have any issue with. Security
is a balance between risk, environment and usability.  The "Safest choice"
is turning your box off or cutting your internet connection. Now hardening
as an option in a global config file for whatever program I have no issue
with just need to be very careful on what is hardened by default and what
is exposed as an option for hardening to those who need it. Also as a
reminder just because something has a hardening option that is disabled by
default that doesn't mean the project ever needs to enable it by default.
Sometimes we add those options and have a migration path/timeline to them
being enabled by default sometimes we just add those options for those who
need them whether by policy, environment, or paranoia.

So a global option in a config file or ENV variable to disable unencrypted
protocols by default is fine. It just should

Also in defense of http is it allows caching. If you are downloading a
signed resource to 10, 100 or 1,000,000 boxes and don't care who knows
caching maybe a very helpful option.

--Nick "darkfiberiru" Wolff



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1885244210.3961054.1600448582022>