From owner-freebsd-arch@FreeBSD.ORG Sun Feb 8 23:10:17 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0436DD9E; Sun, 8 Feb 2015 23:10:17 +0000 (UTC) Received: from mail.karels.net (mail.karels.net [63.231.190.5]) by mx1.freebsd.org (Postfix) with ESMTP id 706E9A11; Sun, 8 Feb 2015 23:10:16 +0000 (UTC) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.14.7/8.14.7) with ESMTP id t18MfjJc091202; Sun, 8 Feb 2015 16:41:47 -0600 (CST) (envelope-from mike@karels.net) Message-Id: <201502082241.t18MfjJc091202@mail.karels.net> From: Mike Karels To: Eric Joyner Reply-to: mike@karels.net Subject: Re: Fwd: Adding new media types to if_media.h In-reply-to: Your message of January 6, 2015 4:50:28 PM CST Date: Sun, 08 Feb 2015 16:41:45 -0600 Cc: Adrian Chadd , Rui Paulo , "freebsd-net@freebsd.org" , John Baldwin , Jack Vogel , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 23:10:17 -0000 Sorry to reply to a thread after such a long delay, but I think it is unresolved, and needs more discussion. I'd like to elaborate a bit on my goals and proposal. I believe Adrian has newer thoughts than have been circulated here as well. The last message(s) have gone to freebsd-arch and freebsd-net. If someone wants to pick one, we could consolidate, but this seems relevant to both. I'm going to top-post to try to summarize and extend the discussion, but the preceding emails follow for reference. To recap: the existing if_media interface is running out of steam, at least in that the "Media variant" field, with 5 bits, is going to be insufficient to express existing 40 Gb/s variants. The if_media media type is a 32-bit int with a bunch of sub-fields for type (e.g. Ethernet), subtype/variant (e.g. 10baseT, 10base5, 1000baseT, etc), flags, and some MII-related fields. I made a proposal to extend the interface in a small way, specifically to replace the "media word" with a 64-bit int that is mostly the same, but has a new, larger variant/subtype field. The main reason for this proposal is to maintain the driver KPI (glimpse showed me 240 inclusions of if_media.h in the kernel in 8.2). That interface includes an initialization using a scalar value of fields ORed with each other. It would also be easy to preserve a 32-bit user-level API/ABI that can express most of the current state, with a subtype/variant field value reserved for "other" (there is already one for "unknown", but that is not quite the same). fwiw, I found 45 references to this user-level API in our tree, including both base and "ports"-type software, which includes libpcap, snmpd, dhclient, quagga, xorp, atm, devd, and rtsold, which argues for a backward-compatible API/ABI as well as a more-complete current interface for ifconfig at least. More generally, I see two problems with the existing if_media interface: 1. It doesn't have enough bits for all the fields, in particular, variant/ subtype for Ethernet. That is the immediate issue. 2. The interface is not sufficiently generic; it was designed around Ethernet including MII, token ring, FDDI, and a few other interface types. Some of the fields like "instance" are primarily for MII as far as I know, and are basically unused. It is definitely not sufficient for 802.11, which has rolled its own interfaces. To solve the second problem, I think the right approach would be to reduce this interface to a truly generic one, such as media type (e.g. Ethernet), generic flags, and perhaps generic status. Then there should be a separate media-specific interface for each type, such as Ethernet and 802.11. To a small extent, we already have that. Solving the second, more general problem, requires a whole new driver KPI that will require surgery to every driver, which is not an exercise that I would consider. Using a separate int for each existing field, as proposed, would break the driver KPI, but would not really make the interface generic. Trying to make a single interface with the union of all network interface requirements seems like a bad idea to me (we failed last time; the "we" is BSDi, where I was the architect when this interface was first designed). (No, I didn't design this interface.) Solving the first problem only, I think it is preferable to preserve a compatible driver KPI, which means using a scalar value encoding what is necessary. Although that interface is rather Ethernet-centric, that is really what it is used for. An additional, selfish goal is to make it easy to back-port drivers using the new interface to older versions (which I am quite likely to do). Preserving the KPI and general user API will be highly useful there. I'd be likely to do a 11-style version of ifconfig personally, but it might not be difficult to do in a more general way. I am willing to do a prototype for -current for evaluation. Comments, alternatives, ? Mike > From: Eric Joyner > Date: January 6, 2015 4:50:28 PM CST > To: mike@karels.net > Cc: Adrian Chadd , Rui Paulo , "freebsd-net@freebsd.org" , Eric Joyner , John Baldwin , Jack Vogel , "freebsd-arch@freebsd.org" > Subject: Re: Adding new media types to if_media.h > > Then going with what Mike says about leaving backwards compatibility, I > suppose we should do something like what Adrian suggested, and add a > separate struct. We can indicate that the separate struct exists by setting > the media type value in the if_media word to 0xc0, since that's the last > unused value. Then existing programs won't have to support any new features > if they don't want to. > > Adrian -- where can I look for more information on what net80211 does for > media types? Do you mean what it does with MCS values, or something more; > I've looked at it a bit, but I don't know very much about how Wi-Fi works. > > - Eric > > On Fri, Dec 12, 2014 at 5:06 PM, Mike Karels wrote: > >>> On Friday, December 12, 2014 12:26:24 PM Jack Vogel wrote: >>>> I think I'd go along with Mike, keeping it simpler seems like a good >> idea. >>>> >>>> Jack >> >>> If the userland ABI impact isn't too broad I think this is fine. Mike, >> do you >>> know off hand how many user-facing things would be affected? >> >> I didn't know off hand, but I have a glimpse index at $WORK (it's for >> McAfee >> Firewall Enterprise, aka Sidewinder, based on 8.2). I found 45 references >> to >> if_media.h at user level, including "ports" that we use, and excluding our >> own software. The list includes libpcap, snmpd, dhclient, quagga, xorp, >> atm, devd, and rtsold. fwiw, I found about 260 inclusions of if_media.h >> in the kernel. >> >> This suggests that we should preserve a backward-compatible user API, even >> if it has limits. Unfortunately, the media word I mentioned is a plain >> int, >> not a typedef. I would propose a similar API that is not limited, but easy >> to convert (e.g. using a new typedef). I'd be willing to sketch out >> something >> like that. >> >>>> On Fri, Dec 12, 2014 at 6:39 AM, Mike Karels wrote: >>>>>> Any other thoughts, or should I start looking at seeing what I can >> take >>>>>> copy from net80211? >>>>>> >>>>>> Also adding -net, since this is pretty relevant. >>>>> >>>>> I had the same reaction as Adrian initially, as an int with numerous >>>>> fields >>>>> seems really messy. However, I don't think we have the challenges of >>>>> 802.11, >>>>> and the only real problem is that the subtype field has run out of >> bits. >>>>> And both ifconfig and the drivers are cast in the form of a scalar >> "media >>>>> word", with parameters to ifmedia_add like IFM_ETHER | IFM_1000_T | >>>>> IFM_FDX >>>>> (assuming that all the bits are in a scalar). >>>>> >>>>> Instead, I would propose that we simply change the media word from >> 32 bits >>>>> to 64, and move the subtype from its current location to a new field >> (e.g. >>>>> 16 bits) in the new space. I believe this can be KPI compatible, >> and it >>>>> is relatively easy to provide a backward-compatible ABI. There >> should be >>>>> a reserved subtype for "other" that can be encoded in the existing >> field >>>>> for use when the subtype can't fit in the old field. This seems much >>>>> easier, >>>>> can be KPI compatible, and will make it much easier to backport >> drivers. >>>>> A backport could simply define the new subtypes as "other", and the >> KPI >>>>> would still be compatible. >>>>> >>>>> Thoughts? >>>>> >>>>> Mike >> >>> -- >>> John Baldwin >> >> Mike >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Mon Feb 9 00:53:59 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 633C4B7F; Mon, 9 Feb 2015 00:53:59 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4E7913C4; Mon, 9 Feb 2015 00:53:59 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 608FB341F90F; Sun, 8 Feb 2015 16:53:53 -0800 (PST) Message-ID: <54D805D1.4050008@freebsd.org> Date: Sun, 08 Feb 2015 16:56:49 -0800 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: mike@karels.net, Eric Joyner Subject: Re: Fwd: Adding new media types to if_media.h References: <201502082241.t18MfjJc091202@mail.karels.net> In-Reply-To: <201502082241.t18MfjJc091202@mail.karels.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , Rui Paulo , "freebsd-net@freebsd.org" , John Baldwin , Jack Vogel , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 00:53:59 -0000 On 2/8/15 2:41 PM, Mike Karels wrote: > > To solve the second problem, I think the right approach would be to reduce > this interface to a truly generic one, such as media type (e.g. Ethernet), > generic flags, and perhaps generic status. Then there should be a separate > media-specific interface for each type, such as Ethernet and 802.11. To a > small extent, we already have that. Solving the second, more general problem, > requires a whole new driver KPI that will require surgery to every driver, > which is not an exercise that I would consider. > > > I am willing to do a prototype for -current for evaluation. > > Comments, alternatives, ? Mike, I think we have enough people to chip in that your concern about breaking the KPI is not as bad as you think. Would like to hear the first correct + long term + less hackish proposal first. Norse has a kernel team that is heavily invested in networking that can help with the transition. If done right, likely renaming ALL of the macros it will be quite trivial to catch all bad cases and move us forward in one great leap. -Alfred From owner-freebsd-arch@FreeBSD.ORG Mon Feb 9 02:49:26 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B45ABA5; Mon, 9 Feb 2015 02:49:26 +0000 (UTC) Received: from mail.karels.net (mail.karels.net [63.231.190.5]) by mx1.freebsd.org (Postfix) with ESMTP id 0DD563D2; Mon, 9 Feb 2015 02:49:25 +0000 (UTC) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.14.7/8.14.7) with ESMTP id t192nI96091798; Sun, 8 Feb 2015 20:49:18 -0600 (CST) (envelope-from mike@karels.net) Message-Id: <201502090249.t192nI96091798@mail.karels.net> To: Alfred Perlstein From: Mike Karels Reply-to: mike@karels.net Subject: Re: Fwd: Adding new media types to if_media.h In-reply-to: Your message of Sun, 08 Feb 2015 16:56:49 -0800. <54D805D1.4050008@freebsd.org> Date: Sun, 08 Feb 2015 20:49:18 -0600 Cc: Adrian Chadd , Rui Paulo , "freebsd-net@freebsd.org" , Eric Joyner , John Baldwin , Jack Vogel , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 02:49:26 -0000 Alfred wrote: > On 2/8/15 2:41 PM, Mike Karels wrote: > > > > To solve the second problem, I think the right approach would be to reduce > > this interface to a truly generic one, such as media type (e.g. Ethernet), > > generic flags, and perhaps generic status. Then there should be a separate > > media-specific interface for each type, such as Ethernet and 802.11. To a > > small extent, we already have that. Solving the second, more general problem, > > requires a whole new driver KPI that will require surgery to every driver, > > which is not an exercise that I would consider. > > > > > > I am willing to do a prototype for -current for evaluation. > > > > Comments, alternatives, ? > Mike, > I think we have enough people to chip in that your concern about > breaking the KPI is not as bad as you think. > Would like to hear the first correct + long term + less hackish proposal > first. > Norse has a kernel team that is heavily invested in networking that can > help with the transition. > If done right, likely renaming ALL of the macros it will be quite > trivial to catch all bad cases and move us forward in one great leap. Don't forget that the KPI is not the only part. Breaking the user-level interface (API/ABI are almost the same) gets into ports and other important software that is harder to change. A new KPI could still provide a compatible API, but would be much constrained. And fwiw, I don't see the advantage to be gained unless the 802.11 software would be much improved. I'm not the one to weigh in on that. Mike From owner-freebsd-arch@FreeBSD.ORG Mon Feb 9 03:45:57 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A55076FF; Mon, 9 Feb 2015 03:45:57 +0000 (UTC) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B5E0C53; Mon, 9 Feb 2015 03:45:57 +0000 (UTC) Received: by iecrd18 with SMTP id rd18so1602163iec.8; Sun, 08 Feb 2015 19:45:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ktt/HK4RMTZXQp75yruCb+atLFWMJmcGH8YZYBHyAP0=; b=LRa2zKbEa1YI4SbLWaYIq/XsYMVgI6JduUYniaMGNJS+Q0T7+Y6a2a07BtXshGdEMA rBFRysFk7a3vdTmjUk37EQCNPRxjP2gMRMa0XEuY2ndJksKxbTNEAD06Dr4dqmVtJp5g P8HExi78DPtBvAkUMT/QVUx+eBoND1/fYhr5zonyWs6CUXFIMW/rVuW4CUeOjN/VtuhD OtjTNLtVuGE25t6Wl0uqLxK588Ux3ixri2pg7SUKJjyawrLmUNIyZ2ORZ0lzQA+pJnPX vW3V/iyFk4cOb7uNohEMFNMJe6pEt41ylcGbnoCicCIHlSFhcOIs2yGDL2+Q+YZkC5IK d6pg== MIME-Version: 1.0 X-Received: by 10.50.93.70 with SMTP id cs6mr14523191igb.6.1423453556085; Sun, 08 Feb 2015 19:45:56 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.17.7 with HTTP; Sun, 8 Feb 2015 19:45:55 -0800 (PST) In-Reply-To: <201502090249.t192nI96091798@mail.karels.net> References: <54D805D1.4050008@freebsd.org> <201502090249.t192nI96091798@mail.karels.net> Date: Sun, 8 Feb 2015 19:45:55 -0800 X-Google-Sender-Auth: 8Byr6a0ac5s-R62D_nu5_aTw7d0 Message-ID: Subject: Re: Fwd: Adding new media types to if_media.h From: Adrian Chadd To: mike@karels.net Content-Type: text/plain; charset=UTF-8 Cc: Rui Paulo , "freebsd-net@freebsd.org" , Alfred Perlstein , Eric Joyner , John Baldwin , Jack Vogel , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 03:45:57 -0000 Hey, don't worry about the wifi side of things - I have absolutely no requirement for backwards compatible API/ABI in the net80211 stack outside of "it makes my life as the maintainer painful." I'm happy to go churn it as part of this in order to get things looking better. (And I likely have to at some point in the future when 11ac support turns up.) -a On 8 February 2015 at 18:49, Mike Karels wrote: > Alfred wrote: >> On 2/8/15 2:41 PM, Mike Karels wrote: >> > >> > To solve the second problem, I think the right approach would be to reduce >> > this interface to a truly generic one, such as media type (e.g. Ethernet), >> > generic flags, and perhaps generic status. Then there should be a separate >> > media-specific interface for each type, such as Ethernet and 802.11. To a >> > small extent, we already have that. Solving the second, more general problem, >> > requires a whole new driver KPI that will require surgery to every driver, >> > which is not an exercise that I would consider. >> > >> > >> > I am willing to do a prototype for -current for evaluation. >> > >> > Comments, alternatives, ? >> Mike, > >> I think we have enough people to chip in that your concern about >> breaking the KPI is not as bad as you think. > >> Would like to hear the first correct + long term + less hackish proposal >> first. > >> Norse has a kernel team that is heavily invested in networking that can >> help with the transition. > >> If done right, likely renaming ALL of the macros it will be quite >> trivial to catch all bad cases and move us forward in one great leap. > > Don't forget that the KPI is not the only part. Breaking the user-level > interface (API/ABI are almost the same) gets into ports and other important > software that is harder to change. A new KPI could still provide a compatible > API, but would be much constrained. And fwiw, I don't see the advantage to > be gained unless the 802.11 software would be much improved. I'm not the > one to weigh in on that. > > Mike From owner-freebsd-arch@FreeBSD.ORG Mon Feb 9 03:51:32 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE115980 for ; Mon, 9 Feb 2015 03:51:32 +0000 (UTC) Received: from mail.umail10.cn4e.com (umail10.cn4e.com [219.239.95.79]) by mx1.freebsd.org (Postfix) with ESMTP id 0362DD1A for ; Mon, 9 Feb 2015 03:51:31 +0000 (UTC) Received: from smail116.cn4e.com (smail116.cn4e.com [124.202.153.116]) by mail.umail10.cn4e.com (Postfix) with ESMTP id 32198FE4494 for ; Mon, 9 Feb 2015 11:51:30 +0800 (CST) X-Bordeaux-Score: 550 X-Spam-Flag: NO Received: from localhost([180.173.154.98]) by smail116.cn4e.com(5.0.0.3a) with ESMTP id 2B13040A0006.220.1423453889.706144; Mon, 09 Feb 2015 11:51:29 +0800 (CST) X-BQId: 2B13040A0006.220.1423453889.706144.1 X-Bordeaux-Type: AUTHSMTP X-35BMId: 2B13040A0006.220.1423453889.706144.1 X-Bordeaux-LOG: SA: TSMF, 3-550-1-83886336,3-550-1-83886336,3-550-1-83886336 eJzt2ctOwkAUBmA2ulHfYZa6YDIFCkiMAWoRQukQGBO3wzBcktIxvSR9Pd/ChW/gG7iyjV2YJhI 2dIier2lOmpzFv/sz07PKt1f8xn5Oi7qubTFktAk2WnVsmA18266Af+L9gJ1wx7eeYTSx8BsSC7 VD9nzCpqivgqXkcdKtm9cmJulT5zdHTwwAKNt5Pov9YQ8dihwluDdUYaQtHtDk84AdOj56DADAC bvIZ7E/ek9siBz6OHK1RQMafaRvDbcw2bPTi6ON9KOt4NFW+SiMhZBhuIq9skICALS6zGexPya9 kYMGMzrpoLsd9/laBqTZFX5VRlJsssuKe22ZwfFl5w+e9sHLnrNnjRBSKy0RAODUXOWz2B8za8o Qo2l7rAIpF+GyygOx6Q7Sj/78AatgDf3xl2X9MbM69jP7fYeOkUwiGfjcQ9mvkIVKSssHANDvC0 JtYqc= X-Bordeaux-Detail: eJxzsrIKjgwOcfW1snIGI0MDYysrE3MrK1MDLidMSRMrKyMDEEaR9YDIGhpaWVkCZY1RZYHIEaz FwAgoZ2WlkVeak6OJZrofyHQgAFLmMCUAqLwmTg== X-Bordeaux-Action-libantispam.so: Action: Relay[NEXT,10000,550:550:550] X-Bordeaux-Action-libspamsa.so: X-Bordeaux-Action-libclamav.so: X-Bordeaux-Action-libsmtpext.so: Message-ID: <2027194190378A2CC0A3C17A8E071F2C3149D8EC75@CN-ETECH.COM> From: "Helen" Reply-To: To: Date: Mon, 9 Feb 2015 11:49:44 +0800 MIME-Version: 1.0 X-Priority: 3 X-Mailer: Joinf MailSystem 8.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 03:51:33 -0000 RGVhciBteSBmcmllbmQ7DQpHb29kIGRheS4NClRoaXMgaXMgSGVsZW4gZnJvbSBFemxpZmUgQ28u LCBMdGQsIGVzdGFibGlzaGVkIGluIDIwMDMuDQpJIGtub3cgeW91IGZyb20gdGhlIGludGVybmV0 Lg0KV2UgYXJlIG9uZSBvZiB0aGUgbGVhZGluZyBjb21wYW5pZXMgaW4gcmVzZWFyY2ggJmRldmVs b3BtZW50LCBwcm9kdWN0aW9uIGFuZCBzYWxlcyBvZiBib2R5IHdhcm1lciwgaGFuZCB3YXJtZXIs IGZvb3Qgd2FybWVyLCB0b2Ugd2FybWVyLCBoZWF0aW5nLCBsaWZlIGdpZnQgcHJvZHVjdHMgaW4g Q2hpbmEuIA0KV2UgaGF2ZSAxMDAgd29ya2VycyBhbmQgYW5udWFsIHByb2R1Y3Rpb24gY2FwYWNp dHkgb2YgbGlmZSBwcm9kdWN0cyBoYXMgcmVhY2hlZCAxNTAsIDAwMCwgMDAwIHBpZWNlcy4NCldl IGhhdmUgZGlmZmVyZW50IGFzc2VtYmx5IGxpbmVzIHRoYXQgYXJlIHN1cGVydmlzZWQgYW5kIG1h bmFnZWQgYnkgcHJvZmVzc2lvbmFsIGRlc2lnbmVycyBhbmQgbWFuYWdlcnMuDQpPdXIgYWltIGlz IHRvIG1ha2UgeW91ciBsaWZlIGVhc3kgYW5kIGhhcHB5IHdpdGggaGlnaCB0ZWNobm9sb2d5Lg0K T3VyIHByb2R1Y3RzIGhhcyBiZWVuIGF3YXJkZWQgd2l0aCBDaGluZXNlLCBVU0EsIEdlcm1hbnks IGV0YyAtICBjZXJ0aWZpY2F0aW9ucy4NCldlIHN0aWxsIG1ha2UgZWZmb3J0cyB0byBzdGVhZGls eSBwcm9ncmVzc2lvbiBhbmQgY3JlYXRpb24gb2YgbmV3IHByb2R1Y3RzLg0KV2UgcHJvdmlkZSBo aWdoIHF1YWxpdHkgcHJvZHVjdCB3aXRoIGNvbXBldGl0aXZlIHByaWNlIGFuZCBwcm9mZXNzaW9u YWwgc2VydmljZS4NCkZyZWUgc2FtcGxlIGlzIGZvciB5b3VyIHRlc3RpbmcgLg0KDQoNCkNvdWxk IHlvdSBnaXZlIHVzIGEgY2hhbmNlIHRvIHNlcnZlIHlvdSBpbiBjb2xvciwgY2F0Y2hlciwgc3Bv cnQgdG93ZWwsIGRhaWx5IGxpZmUgcHJvZHVjdHM/DQpMb29raW5nIGZvcndhcmQgIHRvIHlvdXIg a2luZGx5IHJlcGx5Lg0KDQoNCkJlc3QgUmVnYXJkcyENCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCkhlbGVuIFpoYW5n IA0KU2hhbmdoYWkgRXpsaWZlIENvLiBMdGQNCkFkZDogTm8uNDc5IENodW5kb25nIHJvYWQsTWlu aGFuZyBkaXN0cmljdCwgU2hhbmdoYWkgMjAxMTA4LCBDaGluYQ0KVGVsOjAwODYgMjE1NDcxMDAx MC04MDY3DQpGYXg6MDA4NiAyMSA2MTI5IDQ3NzkNCk1vYihWaWJlci9XaGF0c2FwcCk6IDAwODYg MTU4MDE3OTUwOTQNClNreXBlIElEOiBzaC5zZmZpbHRlY2gzDQpFbWFpbDogc2FsZXMyQGV6bGlm ZWNuLmNvbQ== From owner-freebsd-arch@FreeBSD.ORG Mon Feb 9 18:15:04 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B26885F; Mon, 9 Feb 2015 18:15:04 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E1CEC8F1; Mon, 9 Feb 2015 18:15:03 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t19IF2ln018295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Feb 2015 10:15:02 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t19IF2DM018294; Mon, 9 Feb 2015 10:15:02 -0800 (PST) (envelope-from jmg) Date: Mon, 9 Feb 2015 10:15:02 -0800 From: John-Mark Gurney To: arch@FreeBSD.org Subject: removing bdes.. Message-ID: <20150209181502.GF1953@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Mon, 09 Feb 2015 10:15:02 -0800 (PST) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 18:15:04 -0000 So, I happen to stuble across bdes recently and think we should remove it.. I'm fine w/ making it a port so that people who need it can use it... Especially considering: The DES cipher should no longer be considered secure. Please consider using a more modern alternative. Though sadly, that comment was added almost 15 years after DES was brute forced by DEEPCrack. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Mon Feb 9 21:08:48 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B996CA01; Mon, 9 Feb 2015 21:08:48 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8B7E5EB8; Mon, 9 Feb 2015 21:08:48 +0000 (UTC) Received: from global-1-26.nat.csx.cam.ac.uk ([131.111.184.26]:45145 helo=[172.16.19.1]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1YKvZT-0007mC-Ce; Mon, 09 Feb 2015 16:08:43 -0500 From: "George Neville-Neil" To: "Mike Karels" Subject: Re: Adding new media types to if_media.h Date: Mon, 09 Feb 2015 21:08:41 +0000 Message-ID: In-Reply-To: <201502082241.t18MfjJc091202@mail.karels.net> References: <201502082241.t18MfjJc091202@mail.karels.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9r5054) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com Cc: Adrian Chadd , Rui Paulo , "freebsd-net@freebsd.org" , Eric Joyner , John Baldwin , Jack Vogel , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 21:08:48 -0000 On 8 Feb 2015, at 22:41, Mike Karels wrote: > Sorry to reply to a thread after such a long delay, but I think it is > unresolved, and needs more discussion. I'd like to elaborate a bit on > my goals and proposal. I believe Adrian has newer thoughts than have > been > circulated here as well. > > The last message(s) have gone to freebsd-arch and freebsd-net. If > someone > wants to pick one, we could consolidate, but this seems relevant to > both. > > I'm going to top-post to try to summarize and extend the discussion, > but the > preceding emails follow for reference. > > To recap: the existing if_media interface is running out of steam, at > least > in that the "Media variant" field, with 5 bits, is going to be > insufficient > to express existing 40 Gb/s variants. The if_media media type is a > 32-bit > int with a bunch of sub-fields for type (e.g. Ethernet), > subtype/variant > (e.g. 10baseT, 10base5, 1000baseT, etc), flags, and some MII-related > fields. > > I made a proposal to extend the interface in a small way, specifically > to > replace the "media word" with a 64-bit int that is mostly the same, > but > has a new, larger variant/subtype field. The main reason for this > proposal > is to maintain the driver KPI (glimpse showed me 240 inclusions of > if_media.h > in the kernel in 8.2). That interface includes an initialization > using a > scalar value of fields ORed with each other. It would also be easy to > preserve a 32-bit user-level API/ABI that can express most of the > current > state, with a subtype/variant field value reserved for "other" (there > is > already one for "unknown", but that is not quite the same). fwiw, I > found 45 references to this user-level API in our tree, including both > base and "ports"-type software, which includes libpcap, snmpd, > dhclient, > quagga, xorp, atm, devd, and rtsold, which argues for a > backward-compatible > API/ABI as well as a more-complete current interface for ifconfig at > least. > > More generally, I see two problems with the existing if_media > interface: > > 1. It doesn't have enough bits for all the fields, in particular, > variant/ > subtype for Ethernet. That is the immediate issue. > > 2. The interface is not sufficiently generic; it was designed around > Ethernet > including MII, token ring, FDDI, and a few other interface types. > Some of > the fields like "instance" are primarily for MII as far as I know, and > are > basically unused. It is definitely not sufficient for 802.11, which > has > rolled its own interfaces. > > To solve the second problem, I think the right approach would be to > reduce > this interface to a truly generic one, such as media type (e.g. > Ethernet), > generic flags, and perhaps generic status. Then there should be a > separate > media-specific interface for each type, such as Ethernet and 802.11. > To a > small extent, we already have that. Solving the second, more general > problem, > requires a whole new driver KPI that will require surgery to every > driver, > which is not an exercise that I would consider. > > Using a separate int for each existing field, as proposed, would break > the > driver KPI, but would not really make the interface generic. Trying > to > make a single interface with the union of all network interface > requirements > seems like a bad idea to me (we failed last time; the "we" is BSDi, > where > I was the architect when this interface was first designed). (No, I > didn't > design this interface.) > > Solving the first problem only, I think it is preferable to preserve a > compatible driver KPI, which means using a scalar value encoding what > is > necessary. Although that interface is rather Ethernet-centric, that > is > really what it is used for. > > An additional, selfish goal is to make it easy to back-port drivers > using > the new interface to older versions (which I am quite likely to do). > Preserving the KPI and general user API will be highly useful there. > I'd be likely to do a 11-style version of ifconfig personally, but it > might not be difficult to do in a more general way. > > I am willing to do a prototype for -current for evaluation. > > Comments, alternatives, ? I agree with your statements above and I'd like to see the prototype. Best, George > > Mike > >> From: Eric Joyner >> Date: January 6, 2015 4:50:28 PM CST >> To: mike@karels.net >> Cc: Adrian Chadd , Rui Paulo , >> "freebsd-net@freebsd.org" , Eric Joyner >> , John Baldwin , Jack Vogel >> , "freebsd-arch@freebsd.org" >> >> Subject: Re: Adding new media types to if_media.h >> >> Then going with what Mike says about leaving backwards compatibility, >> I >> suppose we should do something like what Adrian suggested, and add a >> separate struct. We can indicate that the separate struct exists by >> setting >> the media type value in the if_media word to 0xc0, since that's the >> last >> unused value. Then existing programs won't have to support any new >> features >> if they don't want to. >> >> Adrian -- where can I look for more information on what net80211 does >> for >> media types? Do you mean what it does with MCS values, or something >> more; >> I've looked at it a bit, but I don't know very much about how Wi-Fi >> works. >> >> - Eric >> >> On Fri, Dec 12, 2014 at 5:06 PM, Mike Karels wrote: >> >>>> On Friday, December 12, 2014 12:26:24 PM Jack Vogel wrote: >>>>> I think I'd go along with Mike, keeping it simpler seems like a >>>>> good >>> idea. >>>>> >>>>> Jack >>> >>>> If the userland ABI impact isn't too broad I think this is fine. >>>> Mike, >>> do you >>>> know off hand how many user-facing things would be affected? >>> >>> I didn't know off hand, but I have a glimpse index at $WORK (it's >>> for >>> McAfee >>> Firewall Enterprise, aka Sidewinder, based on 8.2). I found 45 >>> references >>> to >>> if_media.h at user level, including "ports" that we use, and >>> excluding our >>> own software. The list includes libpcap, snmpd, dhclient, quagga, >>> xorp, >>> atm, devd, and rtsold. fwiw, I found about 260 inclusions of >>> if_media.h >>> in the kernel. >>> >>> This suggests that we should preserve a backward-compatible user >>> API, even >>> if it has limits. Unfortunately, the media word I mentioned is a >>> plain >>> int, >>> not a typedef. I would propose a similar API that is not limited, >>> but easy >>> to convert (e.g. using a new typedef). I'd be willing to sketch out >>> something >>> like that. >>> >>>>> On Fri, Dec 12, 2014 at 6:39 AM, Mike Karels >>>>> wrote: >>>>>>> Any other thoughts, or should I start looking at seeing what I >>>>>>> can >>> take >>>>>>> copy from net80211? >>>>>>> >>>>>>> Also adding -net, since this is pretty relevant. >>>>>> >>>>>> I had the same reaction as Adrian initially, as an int with >>>>>> numerous >>>>>> fields >>>>>> seems really messy. However, I don't think we have the >>>>>> challenges of >>>>>> 802.11, >>>>>> and the only real problem is that the subtype field has run out >>>>>> of >>> bits. >>>>>> And both ifconfig and the drivers are cast in the form of a >>>>>> scalar >>> "media >>>>>> word", with parameters to ifmedia_add like IFM_ETHER | IFM_1000_T >>>>>> | >>>>>> IFM_FDX >>>>>> (assuming that all the bits are in a scalar). >>>>>> >>>>>> Instead, I would propose that we simply change the media word >>>>>> from >>> 32 bits >>>>>> to 64, and move the subtype from its current location to a new >>>>>> field >>> (e.g. >>>>>> 16 bits) in the new space. I believe this can be KPI compatible, >>> and it >>>>>> is relatively easy to provide a backward-compatible ABI. There >>> should be >>>>>> a reserved subtype for "other" that can be encoded in the >>>>>> existing >>> field >>>>>> for use when the subtype can't fit in the old field. This seems >>>>>> much >>>>>> easier, >>>>>> can be KPI compatible, and will make it much easier to backport >>> drivers. >>>>>> A backport could simply define the new subtypes as "other", and >>>>>> the >>> KPI >>>>>> would still be compatible. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Mike >>> >>>> -- >>>> John Baldwin >>> >>> Mike >>> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to >> "freebsd-net-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to > "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 15:18:15 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A065DFCA for ; Tue, 10 Feb 2015 15:18:15 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B41FB1E for ; Tue, 10 Feb 2015 15:18:15 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YLCZo-000Htq-Rf; Tue, 10 Feb 2015 18:18:12 +0300 Date: Tue, 10 Feb 2015 18:18:12 +0300 From: Slawa Olhovchenkov To: John-Mark Gurney Subject: Re: removing bdes.. Message-ID: <20150210151812.GB67127@zxy.spb.ru> References: <20150209181502.GF1953@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150209181502.GF1953@funkthat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 15:18:15 -0000 On Mon, Feb 09, 2015 at 10:15:02AM -0800, John-Mark Gurney wrote: > So, I happen to stuble across bdes recently and think we should remove > it.. > > I'm fine w/ making it a port so that people who need it can use it... > > Especially considering: > The DES cipher should no longer be considered secure. Please consider > using a more modern alternative. > > Though sadly, that comment was added almost 15 years after DES was > brute forced by DEEPCrack. Clear text also insecure. Do you remove all clear text? From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 17:19:29 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8334E694 for ; Tue, 10 Feb 2015 17:19:29 +0000 (UTC) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 52B21A7E for ; Tue, 10 Feb 2015 17:19:29 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id lj1so42578441pab.6 for ; Tue, 10 Feb 2015 09:19:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=sdANKLyVaw0t/FmZ3uB6PYmjvUgC8nm3WSID0tGaYvo=; b=CdcSC1MMVOwIUq42Kz58v3oVbE1Ow+JmjzGAA18jc3Oa9U08sAboG0PunhkKFDMWrv umsL7mPYjho0nEeowKYpXAcpKGMhYAC+FlguigkZd+pH8VBsB3VfJ8OGQaIKIP54pr4w 5UgSd9M5IrSN+UzhNc/ueMMD9rKhGKFk1DSSbAZe4BeI1a00yVU+a2Jcg1gDkPbCUVj/ CXZLiapaUdLwZQAkNr0f5UHti1wsqVnmRdzoEpyikVJlmuynjVor4vi/Q8E2qzweFGas WJFCQ503L0tK/LEVYLPrsBfA7OOCP2jEJo+V+eicAPnMZQ9+JqOnYbewSyIcijQIgNB0 nEMw== X-Received: by 10.70.126.135 with SMTP id my7mr26743724pdb.135.1423588768798; Tue, 10 Feb 2015 09:19:28 -0800 (PST) Received: from localhost (c-76-21-76-83.hsd1.ca.comcast.net. [76.21.76.83]) by mx.google.com with ESMTPSA id se7sm19862210pbc.84.2015.02.10.09.19.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Feb 2015 09:19:27 -0800 (PST) Sender: Gleb Kurtsou Date: Tue, 10 Feb 2015 09:20:39 -0800 From: Gleb Kurtsou To: Slawa Olhovchenkov Subject: Re: removing bdes.. Message-ID: <20150210172039.GA1071@reks> Mail-Followup-To: Slawa Olhovchenkov , John-Mark Gurney , arch@FreeBSD.org References: <20150209181502.GF1953@funkthat.com> <20150210151812.GB67127@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150210151812.GB67127@zxy.spb.ru> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: arch@FreeBSD.org, John-Mark Gurney X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 17:19:29 -0000 On (10/02/2015 18:18), Slawa Olhovchenkov wrote: > On Mon, Feb 09, 2015 at 10:15:02AM -0800, John-Mark Gurney wrote: > > > So, I happen to stuble across bdes recently and think we should remove > > it.. > > > > I'm fine w/ making it a port so that people who need it can use it... > > > > Especially considering: > > The DES cipher should no longer be considered secure. Please consider > > using a more modern alternative. > > > > Though sadly, that comment was added almost 15 years after DES was > > brute forced by DEEPCrack. > > Clear text also insecure. Do you remove all clear text? This is rather odd argument ;) I'm all for removing it. openssl provides file encryption for those who need it in base. From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 17:43:09 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5EFD8A9C for ; Tue, 10 Feb 2015 17:43:09 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3039AD40 for ; Tue, 10 Feb 2015 17:43:08 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t1AHh2xp029382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2015 09:43:02 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t1AHh18U029381; Tue, 10 Feb 2015 09:43:01 -0800 (PST) (envelope-from jmg) Date: Tue, 10 Feb 2015 09:43:01 -0800 From: John-Mark Gurney To: Slawa Olhovchenkov Subject: Re: removing bdes.. Message-ID: <20150210174301.GT1953@funkthat.com> References: <20150209181502.GF1953@funkthat.com> <20150210151812.GB67127@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150210151812.GB67127@zxy.spb.ru> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Tue, 10 Feb 2015 09:43:02 -0800 (PST) Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 17:43:09 -0000 Slawa Olhovchenkov wrote this message on Tue, Feb 10, 2015 at 18:18 +0300: > On Mon, Feb 09, 2015 at 10:15:02AM -0800, John-Mark Gurney wrote: > > > So, I happen to stuble across bdes recently and think we should remove > > it.. > > > > I'm fine w/ making it a port so that people who need it can use it... > > > > Especially considering: > > The DES cipher should no longer be considered secure. Please consider > > using a more modern alternative. > > > > Though sadly, that comment was added almost 15 years after DES was > > brute forced by DEEPCrack. > > Clear text also insecure. Do you remove all clear text? If I have to answer that question for you, I don't need to respond to you... Once you have a valid argument for keeping it, I'll respond... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 17:50:21 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3173B99 for ; Tue, 10 Feb 2015 17:50:21 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6CFA3E05 for ; Tue, 10 Feb 2015 17:50:21 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YLEwz-000KZZ-Ly; Tue, 10 Feb 2015 20:50:17 +0300 Date: Tue, 10 Feb 2015 20:50:17 +0300 From: Slawa Olhovchenkov To: John-Mark Gurney Subject: Re: removing bdes.. Message-ID: <20150210175017.GC67127@zxy.spb.ru> References: <20150209181502.GF1953@funkthat.com> <20150210151812.GB67127@zxy.spb.ru> <20150210174301.GT1953@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150210174301.GT1953@funkthat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 17:50:21 -0000 On Tue, Feb 10, 2015 at 09:43:01AM -0800, John-Mark Gurney wrote: > Slawa Olhovchenkov wrote this message on Tue, Feb 10, 2015 at 18:18 +0300: > > On Mon, Feb 09, 2015 at 10:15:02AM -0800, John-Mark Gurney wrote: > > > > > So, I happen to stuble across bdes recently and think we should remove > > > it.. > > > > > > I'm fine w/ making it a port so that people who need it can use it... > > > > > > Especially considering: > > > The DES cipher should no longer be considered secure. Please consider > > > using a more modern alternative. > > > > > > Though sadly, that comment was added almost 15 years after DES was > > > brute forced by DEEPCrack. > > > > Clear text also insecure. Do you remove all clear text? > > If I have to answer that question for you, I don't need to respond to > you... > > Once you have a valid argument for keeping it, I'll respond... Keeping support for DES encrypting/decrytpting create vulnerability? or support difficult? What problem resolv removing DES support (and break compatibility)? From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 17:52:42 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E97D7D05 for ; Tue, 10 Feb 2015 17:52:42 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A41B6E34 for ; Tue, 10 Feb 2015 17:52:42 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YLEzI-000Kch-Pn; Tue, 10 Feb 2015 20:52:40 +0300 Date: Tue, 10 Feb 2015 20:52:40 +0300 From: Slawa Olhovchenkov To: John-Mark Gurney , arch@FreeBSD.org Subject: Re: removing bdes.. Message-ID: <20150210175240.GD67127@zxy.spb.ru> References: <20150209181502.GF1953@funkthat.com> <20150210151812.GB67127@zxy.spb.ru> <20150210172039.GA1071@reks> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150210172039.GA1071@reks> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 17:52:43 -0000 On Tue, Feb 10, 2015 at 09:20:39AM -0800, Gleb Kurtsou wrote: > On (10/02/2015 18:18), Slawa Olhovchenkov wrote: > > On Mon, Feb 09, 2015 at 10:15:02AM -0800, John-Mark Gurney wrote: > > > > > So, I happen to stuble across bdes recently and think we should remove > > > it.. > > > > > > I'm fine w/ making it a port so that people who need it can use it... > > > > > > Especially considering: > > > The DES cipher should no longer be considered secure. Please consider > > > using a more modern alternative. > > > > > > Though sadly, that comment was added almost 15 years after DES was > > > brute forced by DEEPCrack. > > > > Clear text also insecure. Do you remove all clear text? > > This is rather odd argument ;) > > I'm all for removing it. openssl provides file encryption for those who > need it in base. 3DES remove too? and how to login users with password in 3DES? How to migrate old system with 3DES passwords? From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 17:58:53 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 669C9F9F for ; Tue, 10 Feb 2015 17:58:53 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 42563E72 for ; Tue, 10 Feb 2015 17:58:53 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t1AHwqmg029551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2015 09:58:52 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t1AHwqeV029550; Tue, 10 Feb 2015 09:58:52 -0800 (PST) (envelope-from jmg) Date: Tue, 10 Feb 2015 09:58:52 -0800 From: John-Mark Gurney To: Slawa Olhovchenkov Subject: Re: removing bdes.. Message-ID: <20150210175852.GV1953@funkthat.com> References: <20150209181502.GF1953@funkthat.com> <20150210151812.GB67127@zxy.spb.ru> <20150210172039.GA1071@reks> <20150210175240.GD67127@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150210175240.GD67127@zxy.spb.ru> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Tue, 10 Feb 2015 09:58:52 -0800 (PST) Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 17:58:53 -0000 Slawa Olhovchenkov wrote this message on Tue, Feb 10, 2015 at 20:52 +0300: > On Tue, Feb 10, 2015 at 09:20:39AM -0800, Gleb Kurtsou wrote: > > > On (10/02/2015 18:18), Slawa Olhovchenkov wrote: > > > On Mon, Feb 09, 2015 at 10:15:02AM -0800, John-Mark Gurney wrote: > > > > > > > So, I happen to stuble across bdes recently and think we should remove > > > > it.. > > > > > > > > I'm fine w/ making it a port so that people who need it can use it... > > > > > > > > Especially considering: > > > > The DES cipher should no longer be considered secure. Please consider > > > > using a more modern alternative. > > > > > > > > Though sadly, that comment was added almost 15 years after DES was > > > > brute forced by DEEPCrack. > > > > > > Clear text also insecure. Do you remove all clear text? > > > > This is rather odd argument ;) > > > > I'm all for removing it. openssl provides file encryption for those who > > need it in base. > > 3DES remove too? and how to login users with password in 3DES? > How to migrate old system with 3DES passwords? Please stay on topic, this has nothing to do w/ the proposed removal of the bdes utility.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 18:01:24 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BDFC9225 for ; Tue, 10 Feb 2015 18:01:24 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D956F17 for ; Tue, 10 Feb 2015 18:01:23 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t1AI1Nc4029600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2015 10:01:23 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t1AI1Ni6029599; Tue, 10 Feb 2015 10:01:23 -0800 (PST) (envelope-from jmg) Date: Tue, 10 Feb 2015 10:01:23 -0800 From: John-Mark Gurney To: Slawa Olhovchenkov Subject: Re: removing bdes.. Message-ID: <20150210180123.GW1953@funkthat.com> References: <20150209181502.GF1953@funkthat.com> <20150210151812.GB67127@zxy.spb.ru> <20150210174301.GT1953@funkthat.com> <20150210175017.GC67127@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150210175017.GC67127@zxy.spb.ru> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Tue, 10 Feb 2015 10:01:23 -0800 (PST) Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 18:01:24 -0000 Slawa Olhovchenkov wrote this message on Tue, Feb 10, 2015 at 20:50 +0300: > On Tue, Feb 10, 2015 at 09:43:01AM -0800, John-Mark Gurney wrote: > > > Slawa Olhovchenkov wrote this message on Tue, Feb 10, 2015 at 18:18 +0300: > > > On Mon, Feb 09, 2015 at 10:15:02AM -0800, John-Mark Gurney wrote: > > > > > > > So, I happen to stuble across bdes recently and think we should remove > > > > it.. > > > > > > > > I'm fine w/ making it a port so that people who need it can use it... > > > > > > > > Especially considering: > > > > The DES cipher should no longer be considered secure. Please consider > > > > using a more modern alternative. > > > > > > > > Though sadly, that comment was added almost 15 years after DES was > > > > brute forced by DEEPCrack. > > > > > > Clear text also insecure. Do you remove all clear text? > > > > If I have to answer that question for you, I don't need to respond to > > you... > > > > Once you have a valid argument for keeping it, I'll respond... > > Keeping support for DES encrypting/decrytpting create vulnerability? > or support difficult? What problem resolv removing DES support (and > break compatibility)? Support difficulty is that we have another piece of software that needs to be maintained... Which is already demonstrated that it wasn't maintained as it took 15 years before someone marked it as insecure... As I said in my original email, if they need bdes, they can just install the port... so no compatibility is broken.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 18:09:08 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97A06594 for ; Tue, 10 Feb 2015 18:09:08 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4E213F84 for ; Tue, 10 Feb 2015 18:09:08 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YLFFC-000Kvo-AJ; Tue, 10 Feb 2015 21:09:06 +0300 Date: Tue, 10 Feb 2015 21:09:06 +0300 From: Slawa Olhovchenkov To: John-Mark Gurney Subject: Re: removing bdes.. Message-ID: <20150210180906.GI3698@zxy.spb.ru> References: <20150209181502.GF1953@funkthat.com> <20150210151812.GB67127@zxy.spb.ru> <20150210172039.GA1071@reks> <20150210175240.GD67127@zxy.spb.ru> <20150210175852.GV1953@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150210175852.GV1953@funkthat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 18:09:08 -0000 On Tue, Feb 10, 2015 at 09:58:52AM -0800, John-Mark Gurney wrote: > Slawa Olhovchenkov wrote this message on Tue, Feb 10, 2015 at 20:52 +0300: > > On Tue, Feb 10, 2015 at 09:20:39AM -0800, Gleb Kurtsou wrote: > > > > > On (10/02/2015 18:18), Slawa Olhovchenkov wrote: > > > > On Mon, Feb 09, 2015 at 10:15:02AM -0800, John-Mark Gurney wrote: > > > > > > > > > So, I happen to stuble across bdes recently and think we should remove > > > > > it.. > > > > > > > > > > I'm fine w/ making it a port so that people who need it can use it... > > > > > > > > > > Especially considering: > > > > > The DES cipher should no longer be considered secure. Please consider > > > > > using a more modern alternative. > > > > > > > > > > Though sadly, that comment was added almost 15 years after DES was > > > > > brute forced by DEEPCrack. > > > > > > > > Clear text also insecure. Do you remove all clear text? > > > > > > This is rather odd argument ;) > > > > > > I'm all for removing it. openssl provides file encryption for those who > > > need it in base. > > > > 3DES remove too? and how to login users with password in 3DES? > > How to migrate old system with 3DES passwords? > > Please stay on topic, this has nothing to do w/ the proposed removal > of the bdes utility.. Ah, bdes utility, sorry. But this is only 20K binary and 25K source and 80K documenation. And need to update ed(1) (keep 80K documentation?) x Prompt for an encryption key which is used in subsequent reads and writes. If a newline alone is entered as the key, then encryption is turned off. Otherwise, echoing is disabled while a key is read. Encryption/decryption is done using the bdes(1) algorithm. From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 18:19:17 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97E1B80B for ; Tue, 10 Feb 2015 18:19:17 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6AD35F2 for ; Tue, 10 Feb 2015 18:19:17 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t1AIJGSt029759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2015 10:19:16 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t1AIJGYu029758; Tue, 10 Feb 2015 10:19:16 -0800 (PST) (envelope-from jmg) Date: Tue, 10 Feb 2015 10:19:16 -0800 From: John-Mark Gurney To: Slawa Olhovchenkov Subject: Re: removing bdes.. Message-ID: <20150210181916.GY1953@funkthat.com> References: <20150209181502.GF1953@funkthat.com> <20150210151812.GB67127@zxy.spb.ru> <20150210172039.GA1071@reks> <20150210175240.GD67127@zxy.spb.ru> <20150210175852.GV1953@funkthat.com> <20150210180906.GI3698@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150210180906.GI3698@zxy.spb.ru> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Tue, 10 Feb 2015 10:19:16 -0800 (PST) Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 18:19:17 -0000 Slawa Olhovchenkov wrote this message on Tue, Feb 10, 2015 at 21:09 +0300: > On Tue, Feb 10, 2015 at 09:58:52AM -0800, John-Mark Gurney wrote: > > > Slawa Olhovchenkov wrote this message on Tue, Feb 10, 2015 at 20:52 +0300: > > > On Tue, Feb 10, 2015 at 09:20:39AM -0800, Gleb Kurtsou wrote: > > > > > > > On (10/02/2015 18:18), Slawa Olhovchenkov wrote: > > > > > On Mon, Feb 09, 2015 at 10:15:02AM -0800, John-Mark Gurney wrote: > > > > > > > > > > > So, I happen to stuble across bdes recently and think we should remove > > > > > > it.. > > > > > > > > > > > > I'm fine w/ making it a port so that people who need it can use it... > > > > > > > > > > > > Especially considering: > > > > > > The DES cipher should no longer be considered secure. Please consider > > > > > > using a more modern alternative. > > > > > > > > > > > > Though sadly, that comment was added almost 15 years after DES was > > > > > > brute forced by DEEPCrack. > > > > > > > > > > Clear text also insecure. Do you remove all clear text? > > > > > > > > This is rather odd argument ;) > > > > > > > > I'm all for removing it. openssl provides file encryption for those who > > > > need it in base. > > > > > > 3DES remove too? and how to login users with password in 3DES? > > > How to migrate old system with 3DES passwords? > > > > Please stay on topic, this has nothing to do w/ the proposed removal > > of the bdes utility.. > > Ah, bdes utility, sorry. > But this is only 20K binary and 25K source and 80K documenation. > And need to update ed(1) (keep 80K documentation?) See my other comment on lack of maintaining the utility... > x Prompt for an encryption key which is used in subsequent reads > and writes. If a newline alone is entered as the key, then > encryption is turned off. Otherwise, echoing is disabled while a > key is read. Encryption/decryption is done using the bdes(1) > algorithm. It turns out that ed has it's own implementation baked in, so removing bdes will not effect ed's functionality... In my search, it looks like I'll take enigma along w/ bdes... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 18:36:41 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10723EF9 for ; Tue, 10 Feb 2015 18:36:41 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BCF9432E for ; Tue, 10 Feb 2015 18:36:40 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YLFfq-000LNa-SD; Tue, 10 Feb 2015 21:36:38 +0300 Date: Tue, 10 Feb 2015 21:36:38 +0300 From: Slawa Olhovchenkov To: John-Mark Gurney Subject: Re: removing bdes.. Message-ID: <20150210183638.GK3698@zxy.spb.ru> References: <20150209181502.GF1953@funkthat.com> <20150210151812.GB67127@zxy.spb.ru> <20150210172039.GA1071@reks> <20150210175240.GD67127@zxy.spb.ru> <20150210175852.GV1953@funkthat.com> <20150210180906.GI3698@zxy.spb.ru> <20150210181916.GY1953@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150210181916.GY1953@funkthat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 18:36:41 -0000 On Tue, Feb 10, 2015 at 10:19:16AM -0800, John-Mark Gurney wrote: > Slawa Olhovchenkov wrote this message on Tue, Feb 10, 2015 at 21:09 +0300: > > On Tue, Feb 10, 2015 at 09:58:52AM -0800, John-Mark Gurney wrote: > > > > > Slawa Olhovchenkov wrote this message on Tue, Feb 10, 2015 at 20:52 +0300: > > > > On Tue, Feb 10, 2015 at 09:20:39AM -0800, Gleb Kurtsou wrote: > > > > > > > > > On (10/02/2015 18:18), Slawa Olhovchenkov wrote: > > > > > > On Mon, Feb 09, 2015 at 10:15:02AM -0800, John-Mark Gurney wrote: > > > > > > > > > > > > > So, I happen to stuble across bdes recently and think we should remove > > > > > > > it.. > > > > > > > > > > > > > > I'm fine w/ making it a port so that people who need it can use it... > > > > > > > > > > > > > > Especially considering: > > > > > > > The DES cipher should no longer be considered secure. Please consider > > > > > > > using a more modern alternative. > > > > > > > > > > > > > > Though sadly, that comment was added almost 15 years after DES was > > > > > > > brute forced by DEEPCrack. > > > > > > > > > > > > Clear text also insecure. Do you remove all clear text? > > > > > > > > > > This is rather odd argument ;) > > > > > > > > > > I'm all for removing it. openssl provides file encryption for those who > > > > > need it in base. > > > > > > > > 3DES remove too? and how to login users with password in 3DES? > > > > How to migrate old system with 3DES passwords? > > > > > > Please stay on topic, this has nothing to do w/ the proposed removal > > > of the bdes utility.. > > > > Ah, bdes utility, sorry. > > But this is only 20K binary and 25K source and 80K documenation. > > And need to update ed(1) (keep 80K documentation?) > > See my other comment on lack of maintaining the utility... Sorry, I am not understand you point ("someone marked it as insecure" -- right?). What need to maintaining in this utility? And what is insecure in this utility? (As I understanding 'insecure' -- allowing to gain unauthorise access or execute unapproved action) > > x Prompt for an encryption key which is used in subsequent reads > > and writes. If a newline alone is entered as the key, then > > encryption is turned off. Otherwise, echoing is disabled while a > > key is read. Encryption/decryption is done using the bdes(1) > > algorithm. > > It turns out that ed has it's own implementation baked in, so removing > bdes will not effect ed's functionality... > > In my search, it looks like I'll take enigma along w/ bdes... I am talk this not about utility bdes, I am talk about bdes.1 man page and bdes.ps. I think not good reference to not-existing man page. May be need to update ed.1? From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 18:55:29 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BAF0791A for ; Tue, 10 Feb 2015 18:55:29 +0000 (UTC) Received: from pmta1.delivery1.ore.mailhop.org (pmta1.delivery1.ore.mailhop.org [54.191.214.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9934E76D for ; Tue, 10 Feb 2015 18:55:29 +0000 (UTC) Received: from smtp4.ore.mailhop.org (172.31.36.112) by pmta1.delivery1.ore.mailhop.org id hr9a1s20r841 for ; Tue, 10 Feb 2015 18:04:53 +0000 (envelope-from ) Received: from [73.34.117.227] (helo=ilsoft.org) by smtp4.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YLFB7-0007Zj-PE; Tue, 10 Feb 2015 18:04:53 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t1AI4p03082753; Tue, 10 Feb 2015 11:04:51 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX18zwIitdkv9iH+31uHxAuMk Message-ID: <1423591491.80968.18.camel@freebsd.org> Subject: Re: removing bdes.. From: Ian Lepore To: Slawa Olhovchenkov Date: Tue, 10 Feb 2015 11:04:51 -0700 In-Reply-To: <20150210175240.GD67127@zxy.spb.ru> References: <20150209181502.GF1953@funkthat.com> <20150210151812.GB67127@zxy.spb.ru> <20150210172039.GA1071@reks> <20150210175240.GD67127@zxy.spb.ru> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, John-Mark Gurney X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 18:55:29 -0000 On Tue, 2015-02-10 at 20:52 +0300, Slawa Olhovchenkov wrote: > On Tue, Feb 10, 2015 at 09:20:39AM -0800, Gleb Kurtsou wrote: > > > On (10/02/2015 18:18), Slawa Olhovchenkov wrote: > > > On Mon, Feb 09, 2015 at 10:15:02AM -0800, John-Mark Gurney wrote: > > > > > > > So, I happen to stuble across bdes recently and think we should remove > > > > it.. > > > > > > > > I'm fine w/ making it a port so that people who need it can use it... > > > > > > > > Especially considering: > > > > The DES cipher should no longer be considered secure. Please consider > > > > using a more modern alternative. > > > > > > > > Though sadly, that comment was added almost 15 years after DES was > > > > brute forced by DEEPCrack. > > > > > > Clear text also insecure. Do you remove all clear text? > > > > This is rather odd argument ;) > > > > I'm all for removing it. openssl provides file encryption for those who > > need it in base. > > 3DES remove too? and how to login users with password in 3DES? > How to migrate old system with 3DES passwords? 3des != bdes. You sure seem to be working hard to invent a problem with a mundane code cleanup. -- Ian From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 19:01:34 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08B99B9B for ; Tue, 10 Feb 2015 19:01:34 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D51357D6 for ; Tue, 10 Feb 2015 19:01:33 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t1AJ1WsD031294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2015 11:01:32 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t1AJ1WGk031293; Tue, 10 Feb 2015 11:01:32 -0800 (PST) (envelope-from jmg) Date: Tue, 10 Feb 2015 11:01:32 -0800 From: John-Mark Gurney To: Slawa Olhovchenkov Subject: Re: removing bdes.. Message-ID: <20150210190132.GB1953@funkthat.com> References: <20150209181502.GF1953@funkthat.com> <20150210151812.GB67127@zxy.spb.ru> <20150210172039.GA1071@reks> <20150210175240.GD67127@zxy.spb.ru> <20150210175852.GV1953@funkthat.com> <20150210180906.GI3698@zxy.spb.ru> <20150210181916.GY1953@funkthat.com> <20150210183638.GK3698@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150210183638.GK3698@zxy.spb.ru> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Tue, 10 Feb 2015 11:01:32 -0800 (PST) Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 19:01:34 -0000 Slawa Olhovchenkov wrote this message on Tue, Feb 10, 2015 at 21:36 +0300: > On Tue, Feb 10, 2015 at 10:19:16AM -0800, John-Mark Gurney wrote: > > > Slawa Olhovchenkov wrote this message on Tue, Feb 10, 2015 at 21:09 +0300: > > > On Tue, Feb 10, 2015 at 09:58:52AM -0800, John-Mark Gurney wrote: > > > > > > > Slawa Olhovchenkov wrote this message on Tue, Feb 10, 2015 at 20:52 +0300: > > > > > On Tue, Feb 10, 2015 at 09:20:39AM -0800, Gleb Kurtsou wrote: > > > > > > > > > > > On (10/02/2015 18:18), Slawa Olhovchenkov wrote: > > > > > > > On Mon, Feb 09, 2015 at 10:15:02AM -0800, John-Mark Gurney wrote: > > > > > > > > > > > > > > > So, I happen to stuble across bdes recently and think we should remove > > > > > > > > it.. > > > > > > > > > > > > > > > > I'm fine w/ making it a port so that people who need it can use it... > > > > > > > > > > > > > > > > Especially considering: > > > > > > > > The DES cipher should no longer be considered secure. Please consider > > > > > > > > using a more modern alternative. > > > > > > > > > > > > > > > > Though sadly, that comment was added almost 15 years after DES was > > > > > > > > brute forced by DEEPCrack. > > > > > > > > > > > > > > Clear text also insecure. Do you remove all clear text? > > > > > > > > > > > > This is rather odd argument ;) > > > > > > > > > > > > I'm all for removing it. openssl provides file encryption for those who > > > > > > need it in base. > > > > > > > > > > 3DES remove too? and how to login users with password in 3DES? > > > > > How to migrate old system with 3DES passwords? > > > > > > > > Please stay on topic, this has nothing to do w/ the proposed removal > > > > of the bdes utility.. > > > > > > Ah, bdes utility, sorry. > > > But this is only 20K binary and 25K source and 80K documenation. > > > And need to update ed(1) (keep 80K documentation?) > > > > See my other comment on lack of maintaining the utility... > > Sorry, I am not understand you point ("someone marked it as insecure" -- right?). Yes, but it took 15 years for someone to do that.. What other issues remain in the utility? > What need to maintaining in this utility? I don't know, but that's the point... Is the risk/cost of this utility more or less than the cost of having this utility... Since I have a feeling that only a handful (none?) of people are currently using this utility, the risk/cost is higher than the benifit of having it... > And what is insecure in this utility? > (As I understanding 'insecure' -- allowing to gain unauthorise access > or execute unapproved action) gain unauthorized access is what is insecure... Any data encrypted using this utility would put the data at risk of an unathorized party gaining access to said data (due to the use of an insecure crypto algorithm)... > > > x Prompt for an encryption key which is used in subsequent reads > > > and writes. If a newline alone is entered as the key, then > > > encryption is turned off. Otherwise, echoing is disabled while a > > > key is read. Encryption/decryption is done using the bdes(1) > > > algorithm. > > > > It turns out that ed has it's own implementation baked in, so removing > > bdes will not effect ed's functionality... > > > > In my search, it looks like I'll take enigma along w/ bdes... > > I am talk this not about utility bdes, I am talk about bdes.1 man page > and bdes.ps. I think not good reference to not-existing man page. > > May be need to update ed.1? We can simply remove the Xr if that really concerns you, but as the port would have the man page it isn't always not-existant... I see some benefit to keeping it, though someone from the -docs team would speak up... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 19:09:49 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 922CAE39 for ; Tue, 10 Feb 2015 19:09:49 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 78BFF8C5 for ; Tue, 10 Feb 2015 19:09:49 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 12740219FB; Tue, 10 Feb 2015 11:09:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1423595389; x=1423609789; bh=l4lehaeKqQXR/5LBYCyTB4PFRZ28Fjj9qo7MsJoUJEU=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=lnIGwHO4A9x9BzqhH1vIL3Ujvpnu/JJthYjKqKUaW9v+CML7DJPVqFAg3XfAuqCYf 5imEsEtJQ6eEvR68L3Dp4BYZRqqgUgKnY/8Gp14d3QHkfsLeyyBE2+zEJHn/5jaYob fGw6w5mc5ZXHCl/nnNIZ7TIi39l19fABYNhPMQCo= Message-ID: <54DA577C.2010808@delphij.net> Date: Tue, 10 Feb 2015 11:09:48 -0800 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: John-Mark Gurney , arch@FreeBSD.org Subject: Re: removing bdes.. References: <20150209181502.GF1953@funkthat.com> In-Reply-To: <20150209181502.GF1953@funkthat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 19:09:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/09/15 10:15, John-Mark Gurney wrote: > So, I happen to stuble across bdes recently and think we should > remove it.. > > I'm fine w/ making it a port so that people who need it can use > it... > > Especially considering: The DES cipher should no longer be > considered secure. Please consider using a more modern > alternative. > > Though sadly, that comment was added almost 15 years after DES was > brute forced by DEEPCrack. I agree, this should be made a port and removed from base. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.1 (FreeBSD) iQIcBAEBCgAGBQJU2ld6AAoJEJW2GBstM+nsFCsP/2FtmD9yhwpcTTNZ9ZEyA9FJ +l3tnb9kV/5dEVQyurkTnO5qulsQzAPCSZfuLZxTVgqRGZsg6ztOwNhPf4/lUjT9 XtAuojc9TtC+UEx3Y+W/2XD0IJjKqSFF/P3EZxUG4qsRAkubAig2Tk3rerEVN6fY Bxr0gQCs4/2aN43K+q/bLEBkz/iokTLmjUnIsL7glRQJsZFb6T9QbEELYLOoEajG SnOC3FGOdavPtu1fjhpxhbZAyhaEASkrYnTm7XeLcQLscgrJwej8s419L0S8vWTD RNLIqyqyJ70aOGZ/zCLFCs+7hd84eepDqTGVW41etYA5kxnkOc0i2gpM4D/Ce/aH Qbri448f8upX4/xJSXBjOv/wjvuZOC9mQN5UEi49dNUga4rD7u9Yjck/H85lMd0z /f73NZsHDTga9XYd73+7apnTRnZYRzL7b/4GzxuFnHkEDQFfzJqJMTubzjDL7DT6 aox+pI5qRUQlYuoaLVBoGfv5VP+IVFukp3rsB+KPjpH7BtYW1tDKpQxBJ4wVHj+9 BYX3k6IsyV6dIq22c6tSPzVAOqM8Z4/ywZ4rpIItYHCczvZCm88AXZmOpj8AjbKw NSELB1J0Rc8TA31kRHEazL+oPcSjSYikgtjzjL4GLaPe6SZY9WXzfDWgXb64Itn4 8bHwJh92lzbtqmPpykMA =fu0M -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 19:13:31 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7707DEFD for ; Tue, 10 Feb 2015 19:13:31 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2FB2D96A for ; Tue, 10 Feb 2015 19:13:31 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YLGFV-000Lzz-8m; Tue, 10 Feb 2015 22:13:29 +0300 Date: Tue, 10 Feb 2015 22:13:29 +0300 From: Slawa Olhovchenkov To: John-Mark Gurney Subject: Re: removing bdes.. Message-ID: <20150210191329.GL3698@zxy.spb.ru> References: <20150209181502.GF1953@funkthat.com> <20150210151812.GB67127@zxy.spb.ru> <20150210172039.GA1071@reks> <20150210175240.GD67127@zxy.spb.ru> <20150210175852.GV1953@funkthat.com> <20150210180906.GI3698@zxy.spb.ru> <20150210181916.GY1953@funkthat.com> <20150210183638.GK3698@zxy.spb.ru> <20150210190132.GB1953@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150210190132.GB1953@funkthat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 19:13:31 -0000 On Tue, Feb 10, 2015 at 11:01:32AM -0800, John-Mark Gurney wrote: > > > > Ah, bdes utility, sorry. > > > > But this is only 20K binary and 25K source and 80K documenation. > > > > And need to update ed(1) (keep 80K documentation?) > > > > > > See my other comment on lack of maintaining the utility... > > > > Sorry, I am not understand you point ("someone marked it as insecure" -- right?). > > Yes, but it took 15 years for someone to do that.. What other issues > remain in the utility? I am missing -- what issuse found in this utility? Insecure algorithm? This is not issuse. > > What need to maintaining in this utility? > > I don't know, but that's the point... Is the risk/cost of this utility > more or less than the cost of having this utility... Since I have a > feeling that only a handful (none?) of people are currently using this > utility, the risk/cost is higher than the benifit of having it... What risk of having not suid, not network utility? > > And what is insecure in this utility? > > (As I understanding 'insecure' -- allowing to gain unauthorise access > > or execute unapproved action) > > gain unauthorized access is what is insecure... Any data encrypted > using this utility would put the data at risk of an unathorized party > gaining access to said data (due to the use of an insecure crypto > algorithm)... Hmm, as I reminder FreeBSD motto is "tools, not policies". If tools work as expected -- all OK. Deny insecure crypto algorithm? Why don't force to use stong crypto algorithm in all places (force disk, swap and memory encryption)? Deny unencrypted network connection? Deny unencrypted arhive? > > > > x Prompt for an encryption key which is used in subsequent reads > > > > and writes. If a newline alone is entered as the key, then > > > > encryption is turned off. Otherwise, echoing is disabled while a > > > > key is read. Encryption/decryption is done using the bdes(1) > > > > algorithm. > > > > > > It turns out that ed has it's own implementation baked in, so removing > > > bdes will not effect ed's functionality... > > > > > > In my search, it looks like I'll take enigma along w/ bdes... > > > > I am talk this not about utility bdes, I am talk about bdes.1 man page > > and bdes.ps. I think not good reference to not-existing man page. > > > > May be need to update ed.1? > > We can simply remove the Xr if that really concerns you, but as the > port would have the man page it isn't always not-existant... I see > some benefit to keeping it, though someone from the -docs team would > speak up... From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 19:49:23 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA684963 for ; Tue, 10 Feb 2015 19:49:23 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BDEA0D1C for ; Tue, 10 Feb 2015 19:49:23 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t1AJnMIb033840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2015 11:49:22 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t1AJnMu5033839; Tue, 10 Feb 2015 11:49:22 -0800 (PST) (envelope-from jmg) Date: Tue, 10 Feb 2015 11:49:22 -0800 From: John-Mark Gurney To: Slawa Olhovchenkov Subject: Re: removing bdes.. Message-ID: <20150210194922.GF1953@funkthat.com> References: <20150209181502.GF1953@funkthat.com> <20150210151812.GB67127@zxy.spb.ru> <20150210172039.GA1071@reks> <20150210175240.GD67127@zxy.spb.ru> <20150210175852.GV1953@funkthat.com> <20150210180906.GI3698@zxy.spb.ru> <20150210181916.GY1953@funkthat.com> <20150210183638.GK3698@zxy.spb.ru> <20150210190132.GB1953@funkthat.com> <20150210191329.GL3698@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150210191329.GL3698@zxy.spb.ru> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Tue, 10 Feb 2015 11:49:23 -0800 (PST) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 19:49:24 -0000 Slawa Olhovchenkov wrote this message on Tue, Feb 10, 2015 at 22:13 +0300: > On Tue, Feb 10, 2015 at 11:01:32AM -0800, John-Mark Gurney wrote: > > > > > > Ah, bdes utility, sorry. > > > > > But this is only 20K binary and 25K source and 80K documenation. > > > > > And need to update ed(1) (keep 80K documentation?) > > > > > > > > See my other comment on lack of maintaining the utility... > > > > > > Sorry, I am not understand you point ("someone marked it as insecure" -- right?). > > > > Yes, but it took 15 years for someone to do that.. What other issues > > remain in the utility? > > I am missing -- what issuse found in this utility? > Insecure algorithm? This is not issuse. Then why is SSL now rumored to be removed from PCI-DSS if algorithm is not a security issue? The entire industry thinks that insecure algorithms are an issue.... If this had been 3DES, I wouldn't be propsing to remove it.. > > > What need to maintaining in this utility? > > > > I don't know, but that's the point... Is the risk/cost of this utility > > more or less than the cost of having this utility... Since I have a > > feeling that only a handful (none?) of people are currently using this > > utility, the risk/cost is higher than the benifit of having it... > > What risk of having not suid, not network utility? There are many risks... Some other suid utility could shell out to use bdes, and due to an exploit in bdes gain root... All code on the system has risk, even if it isn't used... In fact, in some ways, unused code has greater risk as it isn't audited or tested as much as other code... > > > And what is insecure in this utility? > > > (As I understanding 'insecure' -- allowing to gain unauthorise access > > > or execute unapproved action) > > > > gain unauthorized access is what is insecure... Any data encrypted > > using this utility would put the data at risk of an unathorized party > > gaining access to said data (due to the use of an insecure crypto > > algorithm)... > > Hmm, as I reminder FreeBSD motto is "tools, not policies". > If tools work as expected -- all OK. Can you guarantee that this code will? Are you willing to bet your life on this code always functioning w/o any security issues (algorithm not withstanding)... > Deny insecure crypto algorithm? Why don't force to use stong crypto I plan on removing some insecure algorithms from OpenCrypto... If you want to know more, go read the archives on -security about it.. > algorithm in all places (force disk, swap and memory encryption)? Talking about this, I would like to turn on always on encryption for swap, but realize that for some embedded systems, it'll be a hardship.. > Deny unencrypted network connection? I'd like that... turn in tcpinc... Always run https... have http only ever redirect to https, though there are issues w/ that... But sounds like I should deny you ssh, since you seem to think that unencrypted connections are perfectly fine... > Deny unencrypted arhive? At least unauthenticated archive, sure... Too many distributions out there are unauthenticated and pose a security risk... As Xin Li, who is currently acting SO, has spoken and agreed that it should be moved to ports, I'll stop responding to this discussion... We've spent more time talking about this utility, than people have used or even looked at it's code in the last 10 years... If you don't like this decission, bring it up w/ Xin Li or someone else or fork FreeBSD... > > > > > x Prompt for an encryption key which is used in subsequent reads > > > > > and writes. If a newline alone is entered as the key, then > > > > > encryption is turned off. Otherwise, echoing is disabled while a > > > > > key is read. Encryption/decryption is done using the bdes(1) > > > > > algorithm. > > > > > > > > It turns out that ed has it's own implementation baked in, so removing > > > > bdes will not effect ed's functionality... > > > > > > > > In my search, it looks like I'll take enigma along w/ bdes... > > > > > > I am talk this not about utility bdes, I am talk about bdes.1 man page > > > and bdes.ps. I think not good reference to not-existing man page. > > > > > > May be need to update ed.1? > > > > We can simply remove the Xr if that really concerns you, but as the > > port would have the man page it isn't always not-existant... I see > > some benefit to keeping it, though someone from the -docs team would > > speak up... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 20:40:02 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89160C5E for ; Tue, 10 Feb 2015 20:40:02 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3DC1F380 for ; Tue, 10 Feb 2015 20:40:02 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YLHbD-000NpC-Pc; Tue, 10 Feb 2015 23:39:59 +0300 Date: Tue, 10 Feb 2015 23:39:59 +0300 From: Slawa Olhovchenkov To: John-Mark Gurney Subject: Re: removing bdes.. Message-ID: <20150210203959.GN3698@zxy.spb.ru> References: <20150210151812.GB67127@zxy.spb.ru> <20150210172039.GA1071@reks> <20150210175240.GD67127@zxy.spb.ru> <20150210175852.GV1953@funkthat.com> <20150210180906.GI3698@zxy.spb.ru> <20150210181916.GY1953@funkthat.com> <20150210183638.GK3698@zxy.spb.ru> <20150210190132.GB1953@funkthat.com> <20150210191329.GL3698@zxy.spb.ru> <20150210194922.GF1953@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150210194922.GF1953@funkthat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 20:40:02 -0000 On Tue, Feb 10, 2015 at 11:49:22AM -0800, John-Mark Gurney wrote: > Slawa Olhovchenkov wrote this message on Tue, Feb 10, 2015 at 22:13 +0300: > > On Tue, Feb 10, 2015 at 11:01:32AM -0800, John-Mark Gurney wrote: > > > > > > > > Ah, bdes utility, sorry. > > > > > > But this is only 20K binary and 25K source and 80K documenation. > > > > > > And need to update ed(1) (keep 80K documentation?) > > > > > > > > > > See my other comment on lack of maintaining the utility... > > > > > > > > Sorry, I am not understand you point ("someone marked it as insecure" -- right?). > > > > > > Yes, but it took 15 years for someone to do that.. What other issues > > > remain in the utility? > > > > I am missing -- what issuse found in this utility? > > Insecure algorithm? This is not issuse. > > Then why is SSL now rumored to be removed from PCI-DSS if algorithm > is not a security issue? The entire industry thinks that insecure PCI-DSS is as airport security -- banned clear water and cell phones. > algorithms are an issue.... If this had been 3DES, I wouldn't be > propsing to remove it.. Insecure algorithms are an issue if this algorithms are standart service. > > > > What need to maintaining in this utility? > > > > > > I don't know, but that's the point... Is the risk/cost of this utility > > > more or less than the cost of having this utility... Since I have a > > > feeling that only a handful (none?) of people are currently using this > > > utility, the risk/cost is higher than the benifit of having it... > > > > What risk of having not suid, not network utility? > > There are many risks... Some other suid utility could shell out to > use bdes, and due to an exploit in bdes gain root... All code on > the bdes have exploit? or have bad code (mktmp. fgets)? openssl (with strong encryption algorithms) full of known expoit. > system has risk, even if it isn't used... In fact, in some ways, unused > code has greater risk as it isn't audited or tested as much as other > code... You point "this is unused code and prefer to remove" or "weak encryption must be banned"? > > > > And what is insecure in this utility? > > > > (As I understanding 'insecure' -- allowing to gain unauthorise access > > > > or execute unapproved action) > > > > > > gain unauthorized access is what is insecure... Any data encrypted > > > using this utility would put the data at risk of an unathorized party > > > gaining access to said data (due to the use of an insecure crypto > > > algorithm)... > > > > Hmm, as I reminder FreeBSD motto is "tools, not policies". > > If tools work as expected -- all OK. > > Can you guarantee that this code will? Are you willing to bet your > life on this code always functioning w/o any security issues (algorithm > not withstanding)... > > > Deny insecure crypto algorithm? Why don't force to use stong crypto > > I plan on removing some insecure algorithms from OpenCrypto... If > you want to know more, go read the archives on -security about it.. This is break compatibility? As I know some insecure algorithms need for LDAP and PAP/CHAP/NTLM. From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 22:06:05 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08D2134E for ; Tue, 10 Feb 2015 22:06:05 +0000 (UTC) Received: from keltia.net (cl-90.mrs-01.fr.sixxs.net [IPv6:2a01:240:fe00:59::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AEF56F60 for ; Tue, 10 Feb 2015 22:06:04 +0000 (UTC) Received: from [192.168.1.39] (foret.keltia.net [78.232.116.160]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix) with ESMTPSA id D779452AD; Tue, 10 Feb 2015 23:05:58 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: removing bdes.. From: Ollivier Robert X-Mailer: iPad Mail (12B466) In-Reply-To: <20150210191329.GL3698@zxy.spb.ru> Date: Tue, 10 Feb 2015 23:05:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <964BFD22-E04A-40A4-9F82-BEB1AD97EB5A@keltia.net> References: <20150209181502.GF1953@funkthat.com> <20150210151812.GB67127@zxy.spb.ru> <20150210172039.GA1071@reks> <20150210175240.GD67127@zxy.spb.ru> <20150210175852.GV1953@funkthat.com> <20150210180906.GI3698@zxy.spb.ru> <20150210181916.GY1953@funkthat.com> <20150210183638.GK3698@zxy.spb.ru> <20150210190132.GB1953@funkthat.com> <20150210191329.GL3698@zxy.spb.ru> To: Slawa Olhovchenkov Cc: "arch@FreeBSD.org" , John-Mark Gurney X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 22:06:05 -0000 > Hmm, as I reminder FreeBSD motto is "tools, not policies". > If tools work as expected -- all OK. It is also some lines of code no one want to maintain, providing a false sen= se of security, what's the point? > Deny insecure crypto algorithm? Why don't force to use stong crypto > algorithm in all places (force disk, swap and memory encryption)? > Deny unencrypted network connection? > Deny unencrypted arhive? That's besides the point, we are not here to keep old code for the sake of i= t, esp. Since it will be a port. We obsolete old code all the time you know= . I'd say that uucp was more useful than bdes and we still removed it.=20 Why making so big a fuss? --=20 Ollivier Robert= From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 22:18:35 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4FEBA6FC for ; Tue, 10 Feb 2015 22:18:35 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E514122 for ; Tue, 10 Feb 2015 22:18:35 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id B3BA2216E8; Tue, 10 Feb 2015 14:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1423606714; x=1423621114; bh=yHXoTotD+0Vb+2aNbbPOCsfvxyPb0ypyp8WqujJk0IE=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=avq2D1s9wq+pDxu21V7O3b6zA2OqPAMXauFrNhfjPU2a1dN90zHAnh9zAW50H8Ewe LfYOOutlQ7V53lBgT3kJNZVKvfWuek3lUpcOp9qRrulrNsVqoXsdgMoYAp2BWrBL2N WadGldzCUwfKAyMXDru0gd4EAyGroydyKt4H1f1s= Message-ID: <54DA83BA.3010903@delphij.net> Date: Tue, 10 Feb 2015 14:18:34 -0800 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Slawa Olhovchenkov , John-Mark Gurney Subject: Re: removing bdes.. References: <20150210151812.GB67127@zxy.spb.ru> <20150210172039.GA1071@reks> <20150210175240.GD67127@zxy.spb.ru> <20150210175852.GV1953@funkthat.com> <20150210180906.GI3698@zxy.spb.ru> <20150210181916.GY1953@funkthat.com> <20150210183638.GK3698@zxy.spb.ru> <20150210190132.GB1953@funkthat.com> <20150210191329.GL3698@zxy.spb.ru> <20150210194922.GF1953@funkthat.com> <20150210203959.GN3698@zxy.spb.ru> In-Reply-To: <20150210203959.GN3698@zxy.spb.ru> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 22:18:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/10/15 12:39, Slawa Olhovchenkov wrote: > bdes have exploit? or have bad code (mktmp. fgets)? openssl (with > strong encryption algorithms) full of known expoit. bdes(1) is known broken for certain (rare) encryption modes: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=149412 And nobody cared. Its functionality can be implemented using openssl's command line utility, and keep in mind that's an obsolete standard for many years anyways. We don't want to keep multiple implementations of same cryptographic functionality anyways, it's just bad regardless if they are obsolete or not, and bdes(1) have shown exactly why it's bad. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.1 (FreeBSD) iQIcBAEBCgAGBQJU2oO2AAoJEJW2GBstM+nsJpwP/jNiZFu/BPDG3ph0YtC9QyEI CPCnaE0D0c/P8qcf5lSlPPeRBsAY7CLNS7YmffbPrJYO1zJvP9+8GmamHiLVRtZ9 mGD2DI+OmWAp8zXwPk3c5/wploHafScXpe3QZA+w1Ryf6m77Lz1T5FjF4D6BKqnb eqNAXyITZovLfU9aiaagEF2bfnr9FnHaa8hALKWqkGDV0ZpHjwxdbACj4uqMyQFC 9Gek2eW9J137UF5nFZ4E+47VtgnkZIZH+04WEbcvf03KTpENhO/17sAG75WDhu9y 7onbIlOH4PkPfhimS4QBz3NhqtguNEwFVLx6TRnCAvfVvEvrPxfOQgtJP1O2wZds WstnSvTYs42Twrb/+ZUPvKRZ/Vu68sg6YagIjiZKoll40pUGqA3KYkdTge/W8/ea FU/TP/rkZ5wxRPFfcfx7KBqVZ2IPfuGFp4d4yOii2lQCh9ry+wI/iwz0GzSgb7LC Y6fc5HXgRWuqLnpiCQzc64RmzVZgwsy7zuH73sgkKpyu8DVrmgD4F26CF0MZNlXp oKBA0irC9TKYx+wc01xJQ3PPY/2EIAawtF0766JQoNlgbqUjBVxC57poRYiOjtgB p3MSO8edDq2rLWjZ6/kFXx1EVlqgo/69UtT+GeOOtsrccmHq34dRjNOwlfalnIpy tz1B8f7CQHFdg9Z4YpJB =oJgm -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 22:37:39 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE344FE8 for ; Tue, 10 Feb 2015 22:37:39 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5EDFE34F for ; Tue, 10 Feb 2015 22:37:39 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YLJQy-0000IR-VZ; Wed, 11 Feb 2015 01:37:33 +0300 Date: Wed, 11 Feb 2015 01:37:32 +0300 From: Slawa Olhovchenkov To: d@delphij.net Subject: Re: removing bdes.. Message-ID: <20150210223732.GO3698@zxy.spb.ru> References: <20150210175240.GD67127@zxy.spb.ru> <20150210175852.GV1953@funkthat.com> <20150210180906.GI3698@zxy.spb.ru> <20150210181916.GY1953@funkthat.com> <20150210183638.GK3698@zxy.spb.ru> <20150210190132.GB1953@funkthat.com> <20150210191329.GL3698@zxy.spb.ru> <20150210194922.GF1953@funkthat.com> <20150210203959.GN3698@zxy.spb.ru> <54DA83BA.3010903@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54DA83BA.3010903@delphij.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: arch@freebsd.org, John-Mark Gurney X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 22:37:39 -0000 On Tue, Feb 10, 2015 at 02:18:34PM -0800, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 02/10/15 12:39, Slawa Olhovchenkov wrote: > > bdes have exploit? or have bad code (mktmp. fgets)? openssl (with > > strong encryption algorithms) full of known expoit. > > bdes(1) is known broken for certain (rare) encryption modes: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=149412 Good points, thanks. > And nobody cared. I am need to understand FreeBSD team policy. Before this none will be removed from base. Removed because broken and nobody cares -- I am fully appreciate. Removed because implement weak algorithm -- I am dislike this: next step remove any unencryped and broken compatibility and interoperability (like LibreSSL break LANMAN hash support in OpenLDAP). > Its functionality can be implemented using openssl's command line [not bdes advocate] compatibility tested? (And yes, I am not use bdes, I am only ack for protocol). > utility, and keep in mind that's an obsolete standard for many years > anyways. [not bdes advocate] somebody may have very old archive and need too access. > We don't want to keep multiple implementations of same cryptographic > functionality anyways, it's just bad regardless if they are obsolete > or not, and bdes(1) have shown exactly why it's bad. Yes, I see. From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 22:38:59 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0EAD124; Tue, 10 Feb 2015 22:38:59 +0000 (UTC) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 81BCB361; Tue, 10 Feb 2015 22:38:59 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id x3so11662124wes.7; Tue, 10 Feb 2015 14:38:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=MdJvUKcOBY/O7QI5PQV0IxpBSmWPhTiWzaRc//sJ9Ds=; b=u3jmb9cO2Ze1EEcVNflviNYkGy/yXSE3iGe4mqFQlkZ2JiX7zWScliS/HAfjf8jhXZ /9PlTwR+ohmKjT2RTUd7//0oGZq/1Ori8AbcMNYFutOZfMqlYxe9Xb0mnFZCYpNpaWTS Aq0RzIMiSU/SxQluDvy3ief+4Max841we0bwvr07ZW1g8Tywj0lx1Ph4oIpkqndZFkRp R4pTwketJzjNzECRmNUNZW7VXPE9N64qXOuFIA9Sz8D7XOGyfgLK5tU1aC1fQExaCzoI S/rxl1Famlu3v1N8YDI2l4dJ9c3HbhbH+Csj47QmOEMbu/g9tzcstrJaJ6kUWD+lGdio ULGg== X-Received: by 10.180.76.4 with SMTP id g4mr2575592wiw.43.1423607938012; Tue, 10 Feb 2015 14:38:58 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id ub1sm22613042wjc.43.2015.02.10.14.38.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Feb 2015 14:38:57 -0800 (PST) Sender: Baptiste Daroussin Date: Tue, 10 Feb 2015 23:38:54 +0100 From: Baptiste Daroussin To: arch@FreeBSD.org, current@FreeBSD.org Subject: [RFC] Removin the old make Message-ID: <20150210223854.GT29891@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eu12+zRL7gQwOC+E" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 22:39:00 -0000 --eu12+zRL7gQwOC+E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I would like to start using bmake only syntax on our infrastructure for tha= t I want to make sure noone is using the old make, so I plan to remove the old = make =66rom base, I plan to do it by Feb 16th. Note that bmake is the default since FreeBSD 10. FreeBSD 9.3 is also providing bmake (as bmake) on default installation. Best regards, Bapt --eu12+zRL7gQwOC+E Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTaiH4ACgkQ8kTtMUmk6Ey/WwCfeXOBOkWItY21QFLNvmB8lZ6J OWgAoL+mfYRYdkXr2znHStnIXo89dCDZ =FldZ -----END PGP SIGNATURE----- --eu12+zRL7gQwOC+E-- From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 22:45:36 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F28C130D for ; Tue, 10 Feb 2015 22:45:36 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A407861B for ; Tue, 10 Feb 2015 22:45:36 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YLJYh-0000RT-Cb; Wed, 11 Feb 2015 01:45:31 +0300 Date: Wed, 11 Feb 2015 01:45:31 +0300 From: Slawa Olhovchenkov To: Ollivier Robert Subject: Re: removing bdes.. Message-ID: <20150210224531.GP3698@zxy.spb.ru> References: <20150210151812.GB67127@zxy.spb.ru> <20150210172039.GA1071@reks> <20150210175240.GD67127@zxy.spb.ru> <20150210175852.GV1953@funkthat.com> <20150210180906.GI3698@zxy.spb.ru> <20150210181916.GY1953@funkthat.com> <20150210183638.GK3698@zxy.spb.ru> <20150210190132.GB1953@funkthat.com> <20150210191329.GL3698@zxy.spb.ru> <964BFD22-E04A-40A4-9F82-BEB1AD97EB5A@keltia.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <964BFD22-E04A-40A4-9F82-BEB1AD97EB5A@keltia.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: "arch@FreeBSD.org" , John-Mark Gurney X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 22:45:37 -0000 On Tue, Feb 10, 2015 at 11:05:57PM +0100, Ollivier Robert wrote: > > > Hmm, as I reminder FreeBSD motto is "tools, not policies". > > If tools work as expected -- all OK. > > It is also some lines of code no one want to maintain, providing a > false sense of security, what's the point? No. 'security' is (at the least) protection and availability. Unavailability for decryption is insecurity. Even for weak encryption. > > Deny insecure crypto algorithm? Why don't force to use stong crypto > > algorithm in all places (force disk, swap and memory encryption)? > > Deny unencrypted network connection? > > Deny unencrypted arhive? > > That's besides the point, we are not here to keep old code for the > sake of it, esp. Since it will be a port. We obsolete old code all > the time you know. I'd say that uucp was more useful than bdes and > we still removed it. Removing uucp entail inconvenience for me, yes. Thanks for keeping cu (this is part of original uucp), Linux distro force to install minicom. > Why making so big a fuss? I am fuss for policy. Not for bdes as is. From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 22:55:13 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96B3F4D7; Tue, 10 Feb 2015 22:55:13 +0000 (UTC) Received: from www.lemis.com (www.lemis.com [208.86.226.86]) by mx1.freebsd.org (Postfix) with ESMTP id 6D20E75C; Tue, 10 Feb 2015 22:55:13 +0000 (UTC) Received: from eureka.lemis.com (www.lemis.com [208.86.226.86]) by www.lemis.com (Postfix) with ESMTP id 6F5601B72875; Tue, 10 Feb 2015 22:49:39 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id D5E62F75DF; Wed, 11 Feb 2015 09:49:37 +1100 (EST) Date: Wed, 11 Feb 2015 09:49:37 +1100 From: Greg 'groggy' Lehey To: Baptiste Daroussin Subject: Re: [RFC] Removin the old make Message-ID: <20150210224937.GE58387@eureka.lemis.com> References: <20150210223854.GT29891@ivaldir.etoilebsd.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3XA6nns4nE4KvaS/" Content-Disposition: inline In-Reply-To: <20150210223854.GT29891@ivaldir.etoilebsd.net> User-Agent: Mutt/1.4.2.3i Organization: The FreeBSD Project Phone: +61-3-5346-1370 Mobile: None. Use the landline. WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: arch@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 22:55:13 -0000 --3XA6nns4nE4KvaS/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tuesday, 10 February 2015 at 23:38:54 +0100, Baptiste Daroussin wrote: > Hi, > > I would like to start using bmake only syntax on our infrastructure for that I > want to make sure noone is using the old make, so I plan to remove the old make > from base, I plan to do it by Feb 16th. How does this affect non-system Makefiles that depend on pmake? Is bmake completely upward compatible? Greg -- Sent from my desktop computer. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua --3XA6nns4nE4KvaS/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlTaiwEACgkQIubykFB6QiMk6gCgmCrYTA5Duu36AIUYjW4BC6mg JpAAni+896CEY6AdmOUxhKzhGpqkoiJU =Mbkk -----END PGP SIGNATURE----- --3XA6nns4nE4KvaS/-- From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 22:59:46 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB84A7A6; Tue, 10 Feb 2015 22:59:46 +0000 (UTC) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 67A45793; Tue, 10 Feb 2015 22:59:46 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id k48so46873wev.0; Tue, 10 Feb 2015 14:59:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=FHj9dL4HI58mmuFTMP2TrFYnE2dIXNsEBYQxME6xNBk=; b=OWWO68jLOaT89zJWJyUVu8MBOjuJldk51RYSldI9C8aS1pm++bDgJY3zXPnBxVqW5g prniqv6hO9+XoEE11KriGsdgSET694Ukr2dLXwXsixlpYatICaoneHP01onvir+/S6Ol /+MZec1r5IbunDBTZzK8LVE+FZUtD9mDbEqiBqa6LcHSaA3gB6rGUdQxD4IrTdsiv05v 9y8/s7KV+WDp+NJMOpY2PNrQrwY5kJBAG9x1h2OfpACXNYSCYV8zfOZL9uRD4wRdBDYU wJXpbMeErv0FF4APxKnR7hmsYRKKGgXF8oAQRsGEKkLLVqFvL6nx2gHxRLNaASRsm3ZB BBiw== X-Received: by 10.195.17.137 with SMTP id ge9mr57220297wjd.44.1423609184879; Tue, 10 Feb 2015 14:59:44 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id x18sm446600wia.12.2015.02.10.14.59.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Feb 2015 14:59:43 -0800 (PST) Sender: Baptiste Daroussin Date: Tue, 10 Feb 2015 23:59:42 +0100 From: Baptiste Daroussin To: Greg 'groggy' Lehey Subject: Re: [RFC] Removin the old make Message-ID: <20150210225941.GU29891@ivaldir.etoilebsd.net> References: <20150210223854.GT29891@ivaldir.etoilebsd.net> <20150210224937.GE58387@eureka.lemis.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O9T4zNOkGnr0n+A/" Content-Disposition: inline In-Reply-To: <20150210224937.GE58387@eureka.lemis.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: arch@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 22:59:47 -0000 --O9T4zNOkGnr0n+A/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 11, 2015 at 09:49:37AM +1100, Greg 'groggy' Lehey wrote: > On Tuesday, 10 February 2015 at 23:38:54 +0100, Baptiste Daroussin wrote: > > Hi, > > > > I would like to start using bmake only syntax on our infrastructure for= that I > > want to make sure noone is using the old make, so I plan to remove the = old make > > from base, I plan to do it by Feb 16th. >=20 > How does this affect non-system Makefiles that depend on pmake? Is > bmake completely upward compatible? There are very few issues, not that fmake is available from ports, I think = 99% of the compatibility are preserved I know about a couple of incompatibiliti= es that are bothering me in ports (for the infrastructure) but I would say thi= s is very much a corner case Bapt --O9T4zNOkGnr0n+A/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTajV0ACgkQ8kTtMUmk6EyP+QCfdt0cIK357EaAD/cCWMCBs3KH nEMAoLpV5H2BNrASUe7McksuZGAauuHA =NOp1 -----END PGP SIGNATURE----- --O9T4zNOkGnr0n+A/-- From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 23:04:20 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87473A11; Tue, 10 Feb 2015 23:04:20 +0000 (UTC) Received: from pmta2.delivery7.ore.mailhop.org (pmta2.delivery7.ore.mailhop.org [54.149.205.143]) by mx1.freebsd.org (Postfix) with ESMTP id 639A4857; Tue, 10 Feb 2015 23:04:20 +0000 (UTC) Received: from smtp3.ore.mailhop.org (172.31.18.134) by pmta2.delivery1.ore.mailhop.org id hra77c20u50l; Tue, 10 Feb 2015 23:04:20 +0000 (envelope-from ) Received: from [73.34.117.227] (helo=ilsoft.org) by smtp3.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YLJqs-0001vF-Tc; Tue, 10 Feb 2015 23:04:19 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t1AN4GHg084439; Tue, 10 Feb 2015 16:04:16 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX1/oAv7KrH+YvidictCHe4wq Message-ID: <1423609456.80968.32.camel@freebsd.org> Subject: Re: [RFC] Removin the old make From: Ian Lepore To: Baptiste Daroussin Date: Tue, 10 Feb 2015 16:04:16 -0700 In-Reply-To: <20150210225941.GU29891@ivaldir.etoilebsd.net> References: <20150210223854.GT29891@ivaldir.etoilebsd.net> <20150210224937.GE58387@eureka.lemis.com> <20150210225941.GU29891@ivaldir.etoilebsd.net> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: Greg 'groggy' Lehey , arch@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 23:04:20 -0000 On Tue, 2015-02-10 at 23:59 +0100, Baptiste Daroussin wrote: > On Wed, Feb 11, 2015 at 09:49:37AM +1100, Greg 'groggy' Lehey wrote: > > On Tuesday, 10 February 2015 at 23:38:54 +0100, Baptiste Daroussin wrote: > > > Hi, > > > > > > I would like to start using bmake only syntax on our infrastructure for that I > > > want to make sure noone is using the old make, so I plan to remove the old make > > > from base, I plan to do it by Feb 16th. > > > > How does this affect non-system Makefiles that depend on pmake? Is > > bmake completely upward compatible? > > There are very few issues, not that fmake is available from ports, I think 99% > of the compatibility are preserved I know about a couple of incompatibilities > that are bothering me in ports (for the infrastructure) but I would say this is > very much a corner case > > Bapt By far the biggest incompatibility I've run into is the change from :U and :L to :tu and :tl, mostly because any existing makefiles that contain :U or :L variable modifiers just silently do the wrong thing under bmake. It's especially annoying because :L is really common in fmake and its meaning in bmake is all but useless. -- Ian From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 23:06:02 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D1C8BC0; Tue, 10 Feb 2015 23:06:02 +0000 (UTC) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EAA2F870; Tue, 10 Feb 2015 23:06:01 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id p10so56952wes.2; Tue, 10 Feb 2015 15:06:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=11erkOPs6IziL1IEoZg6Jz18q2RzeEtIw/bHqZqxF5M=; b=VTr87p3BjxoG1w3/j0tajl3sSi+jAhlaJjEeZSG0jjcHmp/ULYFg4Zr4+SSa9frnCB AbHFozjI8u2jh35R4g3ukIWefc/RgUlz8VKEPcbkacOesBlaR6KvTexQQPBVuSdIzANg c0oeomgW4YOqjbJKUhubCJaR+E1Stlhyx/n0GjpMhkVywIc0m1dgwZmKej/kSp/Kxw/G CDsldDDArnfUPH3vUoTKkNpvR/3/ML1X7g5xBXkTgvb/cNbPNZs0OZ9NZZrPri77t7/o rlltB5T22o+t3TlI4mgduHb6D3wpwLDVRJ2q0XgG05g9FDoSTfkvLc/OHDceDHqaC5Bu x6hQ== X-Received: by 10.180.75.39 with SMTP id z7mr153466wiv.78.1423609560492; Tue, 10 Feb 2015 15:06:00 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id dm6sm435101wib.22.2015.02.10.15.05.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Feb 2015 15:05:59 -0800 (PST) Sender: Baptiste Daroussin Date: Wed, 11 Feb 2015 00:05:57 +0100 From: Baptiste Daroussin To: Ian Lepore Subject: Re: [RFC] Removin the old make Message-ID: <20150210230557.GV29891@ivaldir.etoilebsd.net> References: <20150210223854.GT29891@ivaldir.etoilebsd.net> <20150210224937.GE58387@eureka.lemis.com> <20150210225941.GU29891@ivaldir.etoilebsd.net> <1423609456.80968.32.camel@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6h64vBu9tReNbGLX" Content-Disposition: inline In-Reply-To: <1423609456.80968.32.camel@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Greg 'groggy' Lehey , arch@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 23:06:02 -0000 --6h64vBu9tReNbGLX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 10, 2015 at 04:04:16PM -0700, Ian Lepore wrote: > On Tue, 2015-02-10 at 23:59 +0100, Baptiste Daroussin wrote: > > On Wed, Feb 11, 2015 at 09:49:37AM +1100, Greg 'groggy' Lehey wrote: > > > On Tuesday, 10 February 2015 at 23:38:54 +0100, Baptiste Daroussin wr= ote: > > > > Hi, > > > > > > > > I would like to start using bmake only syntax on our infrastructure= for that I > > > > want to make sure noone is using the old make, so I plan to remove = the old make > > > > from base, I plan to do it by Feb 16th. > > >=20 > > > How does this affect non-system Makefiles that depend on pmake? Is > > > bmake completely upward compatible? > >=20 > > There are very few issues, not that fmake is available from ports, I th= ink 99% > > of the compatibility are preserved I know about a couple of incompatibi= lities > > that are bothering me in ports (for the infrastructure) but I would say= this is > > very much a corner case > >=20 > > Bapt >=20 > By far the biggest incompatibility I've run into is the change from :U > and :L to :tu and :tl, mostly because any existing makefiles that > contain :U or :L variable modifiers just silently do the wrong thing > under bmake. It's especially annoying because :L is really common in > fmake and its meaning in bmake is all but useless. >=20 Ah yes I forgot that one :) which is the reason why I have blocked migratio= n to bmake for a while :) Still fmake is available via ports so might not be a problem Best regards, Bapt --6h64vBu9tReNbGLX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTajtUACgkQ8kTtMUmk6EzyxwCeI9Lt4UPGBa4I6GP0Z/d7Lby5 wscAn3z73P1UI1G7vKpqjYBy4LiEbmg0 =8uZ8 -----END PGP SIGNATURE----- --6h64vBu9tReNbGLX-- From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 23:12:56 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5DB8EF1; Tue, 10 Feb 2015 23:12:56 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9F099961; Tue, 10 Feb 2015 23:12:56 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t1ANDSUf060872; Tue, 10 Feb 2015 15:13:29 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: arch@FreeBSD.org, current@FreeBSD.org, Baptiste Daroussin In-Reply-To: <20150210223854.GT29891@ivaldir.etoilebsd.net> References: <20150210223854.GT29891@ivaldir.etoilebsd.net> From: "Chris H" Subject: Re: [RFC] Removin the old make Date: Tue, 10 Feb 2015 15:13:29 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <006eaa48dacb4a495a498088d7554af3@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 23:12:56 -0000 On Tue, 10 Feb 2015 23:38:54 +0100 Baptiste Daroussin wrote > Hi, > > I would like to start using bmake only syntax on our infrastructure for that > I want to make sure noone is using the old make, so I plan to remove the old > make from base, I plan to do it by Feb 16th. Please note; I am not expressing any objection to it's removal. But would a 30-day window not be a more friendly. So as to better accommodate those whom will need to make the/a transition? --Chris > > Note that bmake is the default since FreeBSD 10. > FreeBSD 9.3 is also providing bmake (as bmake) on default installation. > > Best regards, > Bapt From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 23:20:11 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1CA2D2A6; Tue, 10 Feb 2015 23:20:11 +0000 (UTC) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B4FE9A1; Tue, 10 Feb 2015 23:20:10 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id b13so120907wgh.0; Tue, 10 Feb 2015 15:20:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=9r6ktYZMB825XwgV16cG5DAsX4PuJcA15SRed+VWlGo=; b=DqQQTZMkBsVg2Vg1X1RzZZNOGsnE2hUgrJ6FaK6sSSc9xRNa7/H4NoNieNe0EfVpha vGJqGfPZExbDaDuF8vaYevOmw94dN60wW92ruHhnRquelQ2TnR4mPNJ4Akh9qONzcFCi fKtqEGT6+3MS+jTtvz+1ns+VMVYoHGVfEU/6BBDpOq6SlJ2jtLPleucIzUx/eF45Uozj Pc+lNNXJxOdhupnwVUQModVM/6XiR68yAGf1cMasqEALzU6UBohG78+yFr2fHckOKbtM WZUzAHLdNsmivdjgvPyla0f7Jkqj9obI0Q3rJXQ0pHGv7wWNO5nk2ZJ74MUImARhrCW0 EvyA== X-Received: by 10.180.97.2 with SMTP id dw2mr348731wib.6.1423610409090; Tue, 10 Feb 2015 15:20:09 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id qg4sm15173707wic.13.2015.02.10.15.20.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Feb 2015 15:20:08 -0800 (PST) Sender: Baptiste Daroussin Date: Wed, 11 Feb 2015 00:20:05 +0100 From: Baptiste Daroussin To: Chris H Subject: Re: [RFC] Removin the old make Message-ID: <20150210232005.GW29891@ivaldir.etoilebsd.net> References: <20150210223854.GT29891@ivaldir.etoilebsd.net> <006eaa48dacb4a495a498088d7554af3@ultimatedns.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L+ytD9kXoSFEJYhc" Content-Disposition: inline In-Reply-To: <006eaa48dacb4a495a498088d7554af3@ultimatedns.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: arch@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 23:20:11 -0000 --L+ytD9kXoSFEJYhc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 10, 2015 at 03:13:29PM -0800, Chris H wrote: > On Tue, 10 Feb 2015 23:38:54 +0100 Baptiste Daroussin = wrote >=20 > > Hi, > >=20 > > I would like to start using bmake only syntax on our infrastructure for= that > > I want to make sure noone is using the old make, so I plan to remove th= e old > > make from base, I plan to do it by Feb 16th. > Please note; I am not expressing any objection to it's removal. > But would a 30-day window not be a more friendly. So as to better > accommodate those whom will need to make the/a transition? >=20 What transition, since 10.0 noone have fmake by default anymore? if one wan= t to keep using fmake he has to explicitly state it when building. Not that I'm against a 30-day windows but that does not seems worth it. Best regards, Bapt --L+ytD9kXoSFEJYhc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTakiUACgkQ8kTtMUmk6Ewx6ACglQ89WgR+Z4IUxkNVqpX74ocB 874AnRLjn6Ic4AjVdFtI0uct7kdSRu27 =RUMM -----END PGP SIGNATURE----- --L+ytD9kXoSFEJYhc-- From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 23:26:50 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D03084C6; Tue, 10 Feb 2015 23:26:50 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 95A3CA88; Tue, 10 Feb 2015 23:26:50 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t1ANRMpm065140; Tue, 10 Feb 2015 15:27:22 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Baptiste Daroussin In-Reply-To: <20150210232005.GW29891@ivaldir.etoilebsd.net> References: <20150210223854.GT29891@ivaldir.etoilebsd.net> <006eaa48dacb4a495a498088d7554af3@ultimatedns.net>, <20150210232005.GW29891@ivaldir.etoilebsd.net> From: "Chris H" Subject: Re: [RFC] Removin the old make Date: Tue, 10 Feb 2015 15:27:22 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <612bc34dbea4014f25aab1290a6ad189@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: arch@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 23:26:50 -0000 On Wed, 11 Feb 2015 00:20:05 +0100 Baptiste Daroussin wrote > On Tue, Feb 10, 2015 at 03:13:29PM -0800, Chris H wrote: > > On Tue, 10 Feb 2015 23:38:54 +0100 Baptiste Daroussin > > wrote > > > Hi, > > > > > > I would like to start using bmake only syntax on our infrastructure for > > > that I want to make sure noone is using the old make, so I plan to remove > > > the old make from base, I plan to do it by Feb 16th. > > Please note; I am not expressing any objection to it's removal. > > But would a 30-day window not be a more friendly. So as to better > > accommodate those whom will need to make the/a transition? > > > What transition, since 10.0 noone have fmake by default anymore? if one want > to keep using fmake he has to explicitly state it when building. Ahh. Sure. In all honesty, it was probably more of a "knee jerk" reaction on my part, when I noticed it was only a week away. :) > > Not that I'm against a 30-day windows but that does not seems worth it. > > Best regards, > Bapt --Chris -- From owner-freebsd-arch@FreeBSD.ORG Thu Feb 12 00:30:24 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D27231D for ; Thu, 12 Feb 2015 00:30:24 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1411B3F7 for ; Thu, 12 Feb 2015 00:30:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id t1C0UNbg084892 for ; Thu, 12 Feb 2015 00:30:23 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id t1C0UNQB084889 for arch@freebsd.org; Thu, 12 Feb 2015 00:30:23 GMT (envelope-from bdrewery) Received: (qmail 94482 invoked from network); 11 Feb 2015 18:30:21 -0600 Received: from unknown (HELO ?10.10.1.139?) (freebsd@shatow.net@10.10.1.139) by sweb.xzibition.com with ESMTPA; 11 Feb 2015 18:30:21 -0600 Message-ID: <54DBF417.4050206@FreeBSD.org> Date: Wed, 11 Feb 2015 18:30:15 -0600 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Fixing dlopen("libpthread.so") References: <20141226165337.GJ1754@kib.kiev.ua> In-Reply-To: <20141226165337.GJ1754@kib.kiev.ua> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uqQesVRhT3Cr78iS9TWbomwC5tot1vB4H" Cc: threads@freebsd.org, arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 00:30:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uqQesVRhT3Cr78iS9TWbomwC5tot1vB4H Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/26/2014 10:53 AM, Konstantin Belousov wrote: > [Long] > Proposed patch does the following: [...] It seems libthr.3 needs to be updated for the dlopen(3) support, to remove some of r272070. Also note the ordering comment (which I know you may not be ready to change yet). > INTERACTION WITH RUN-TIME LINKER > The libthr library must appear before libc in the global order of > depended objects. >=20 > Loading libthr with the dlopen(3) call in the process after the pr= ogram > binary is activated is not supported, and causes miscellaneous and= hard- > to-diagnose misbehaviour. This is due to libthr interposing sever= al > important libc symbols to provide thread-safe services. In partic= ular, > errno and the locking stubs from libc are affected. This requirem= ent is > currently not enforced. >=20 > If the program loads any modules at run-time, and those modules ma= y > require threading services, the main program binary must be linked= with > libpthread, even if it does not require any services from the libr= ary. >=20 > libthr cannot be unloaded; the dlclose(3) function does not perfor= m any > action when called with a handle for libthr. One of the reasons i= s that > the interposing of libc functions cannot be undone. As for the dlclose(3) refusing to work on libthr, I cannot find the supporting code. Where is it? Thanks, Bryan --uqQesVRhT3Cr78iS9TWbomwC5tot1vB4H Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJU2/QfAAoJEDXXcbtuRpfPNEQIAJHLs6BDBmKoHfKdtNJF/Fqq WFfnHY8niMTgsF9EXQfOmBNxROXYKNK8oQjvJ0jLD1k0Ep1bhKDARBntxf55R6yc oueO2rdMH7014WEcNLGbLQF5jkpcpN0SsgGaNfNpMVqlUeVDnAhkglVG/xKPUgC6 bIjeja4/YWD5lXA4P/lwIPbJHbuhAoYfdoz2oyJ1umhQskbPjj1GYU3fpUr9hX1C zQBdSDlC/hkDFuO6gsan2/S5471tEMV0YcaeLRVaqjJYjk6MO0pmcF8Ta7OPdRkr 3sBQfWt/wTygDwyoL+xcuRDbibEfi0Kk8/FaPonyiN/gdf6ll8uOLx0W+as1v8g= =Vz97 -----END PGP SIGNATURE----- --uqQesVRhT3Cr78iS9TWbomwC5tot1vB4H-- From owner-freebsd-arch@FreeBSD.ORG Thu Feb 12 09:27:38 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE82626D; Thu, 12 Feb 2015 09:27:37 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6836E33E; Thu, 12 Feb 2015 09:27:34 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t1C9RTnr061044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2015 11:27:29 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t1C9RTnr061044 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t1C9RTsi061043; Thu, 12 Feb 2015 11:27:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 12 Feb 2015 11:27:28 +0200 From: Konstantin Belousov To: Bryan Drewery Subject: Re: Fixing dlopen("libpthread.so") Message-ID: <20150212092728.GE34251@kib.kiev.ua> References: <20141226165337.GJ1754@kib.kiev.ua> <54DBF417.4050206@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54DBF417.4050206@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: threads@freebsd.org, arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 09:27:38 -0000 On Wed, Feb 11, 2015 at 06:30:15PM -0600, Bryan Drewery wrote: > On 12/26/2014 10:53 AM, Konstantin Belousov wrote: > > [Long] > > Proposed patch does the following: > [...] > > It seems libthr.3 needs to be updated for the dlopen(3) support, to > remove some of r272070. Also note the ordering comment (which I know you > may not be ready to change yet). Thanks for noting, I forgot about the man page and about the text. See the patch at the end of the message. > As for the dlclose(3) refusing to work on libthr, I cannot find the > supporting code. Where is it? libthr is linked with -z nodelete linker flag. diff --git a/lib/libthr/libthr.3 b/lib/libthr/libthr.3 index 4b636ce..8108e2f 100644 --- a/lib/libthr/libthr.3 +++ b/lib/libthr/libthr.3 @@ -1,5 +1,5 @@ .\" Copyright (c) 2005 Robert N. M. Watson -.\" Copyright (c) 2014 The FreeBSD Foundation, Inc. +.\" Copyright (c) 2014,2015 The FreeBSD Foundation, Inc. .\" All rights reserved. .\" .\" Part of this documentation was written by @@ -29,7 +29,7 @@ .\" .\" $FreeBSD$ .\" -.Dd September 26, 2014 +.Dd February 12, 2015 .Dt LIBTHR 3 .Os .Sh NAME @@ -200,45 +200,25 @@ Bigger values reduce the frequency of the FIFO discipline. The value must be between 0 and 255. .El .Sh INTERACTION WITH RUN-TIME LINKER -The +On load, .Nm -library must appear before -.Li libc -in the global order of depended objects. -.Pp -Loading -.Nm -with the -.Xr dlopen 3 -call in the process after the program binary is activated -is not supported, and causes miscellaneous and hard-to-diagnose misbehaviour. -This is due to -.Nm -interposing several important -.Li libc -symbols to provide thread-safe services. -In particular, -.Dv errno -and the locking stubs from -.Li libc -are affected. -This requirement is currently not enforced. -.Pp -If the program loads any modules at run-time, and those modules may require -threading services, the main program binary must be linked with -.Li libpthread , -even if it does not require any services from the library. +installs interposing handlers into the hooks exported by +.Li libc . +The interposers provide real locking implementation instead of the +stubs for single-threaded processes in +.Li , +cancellation support and some modifications to the signal operations. .Pp .Nm cannot be unloaded; the .Xr dlclose 3 function does not perform any action when called with a handle for .Nm . -One of the reasons is that the interposing of +One of the reasons is that the internal interposing of .Li libc functions cannot be undone. .Sh SIGNALS -The implementation also interposes the user-installed +The implementation interposes the user-installed .Xr signal 3 handlers. This interposing is done to postpone signal delivery to threads which From owner-freebsd-arch@FreeBSD.ORG Thu Feb 12 16:57:10 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93FFBC37 for ; Thu, 12 Feb 2015 16:57:10 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5AE3DCB3 for ; Thu, 12 Feb 2015 16:57:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id t1CGvAj7023292 for ; Thu, 12 Feb 2015 16:57:10 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id t1CGvAfE023290 for arch@freebsd.org; Thu, 12 Feb 2015 16:57:10 GMT (envelope-from bdrewery) Received: (qmail 25728 invoked from network); 12 Feb 2015 10:57:07 -0600 Received: from unknown (HELO ?10.10.1.139?) (freebsd@shatow.net@10.10.1.139) by sweb.xzibition.com with ESMTPA; 12 Feb 2015 10:57:07 -0600 Message-ID: <54DCDB69.1000609@FreeBSD.org> Date: Thu, 12 Feb 2015 10:57:13 -0600 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Fixing dlopen("libpthread.so") References: <20141226165337.GJ1754@kib.kiev.ua> <54DBF417.4050206@FreeBSD.org> <20150212092728.GE34251@kib.kiev.ua> In-Reply-To: <20150212092728.GE34251@kib.kiev.ua> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wIg4sUGK1H0xGfQ40t3FjNs3iaWXiGWCx" Cc: threads@freebsd.org, arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 16:57:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wIg4sUGK1H0xGfQ40t3FjNs3iaWXiGWCx Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/12/2015 3:27 AM, Konstantin Belousov wrote: > On Wed, Feb 11, 2015 at 06:30:15PM -0600, Bryan Drewery wrote: >> On 12/26/2014 10:53 AM, Konstantin Belousov wrote: >>> [Long] >>> Proposed patch does the following: >> [...] >> >> It seems libthr.3 needs to be updated for the dlopen(3) support, to >> remove some of r272070. Also note the ordering comment (which I know y= ou >> may not be ready to change yet). > Thanks for noting, I forgot about the man page and about the text. > See the patch at the end of the message. Looks good. >=20 >> As for the dlclose(3) refusing to work on libthr, I cannot find the >> supporting code. Where is it? > libthr is linked with -z nodelete linker flag. >=20 Ah! Thanks. Regards, Bryan Drewery --wIg4sUGK1H0xGfQ40t3FjNs3iaWXiGWCx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJU3NtpAAoJEDXXcbtuRpfPg8QH/2P4iJ2iJKASkZmT4XWkAdGw Hqivvl5wn+tpE8YNE0PL+EzkqoFvka/KohyVX1jw1NRsDtnL5sVAQ7nxI0bDZrR1 x+gfETl8y/QOa3+ORd+7CcaDhuuc3NP0TA/DNMTMTlvEUyqnO/5IY3NqSQJzq/Mt 4OHqlqyjy39XwiDv1feXKurZIjpkBSpT7clF3KYKDITZ3TMHRdZUF+P31vJfC7t8 ohylRpRH49cV0CDEQiZNTEmKOM+IRUYnuPcf9jMKwkI10BUY1YZMUU1GVYqcT/y/ kJMGUeyetk11jz0xMFwrUrUXtsESRbaOcn1cBq0/4Ucfm8rYu+yuXfC/pTDtGDo= =i3vX -----END PGP SIGNATURE----- --wIg4sUGK1H0xGfQ40t3FjNs3iaWXiGWCx-- From owner-freebsd-arch@FreeBSD.ORG Thu Feb 12 22:20:47 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 600DC70E; Thu, 12 Feb 2015 22:20:47 +0000 (UTC) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0114.outbound.protection.outlook.com [207.46.100.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC778691; Thu, 12 Feb 2015 22:20:46 +0000 (UTC) Received: from BLUPR05CA0081.namprd05.prod.outlook.com (10.141.20.51) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.1.81.19; Thu, 12 Feb 2015 22:04:32 +0000 Received: from BY2FFO11FD004.protection.gbl (2a01:111:f400:7c0c::185) by BLUPR05CA0081.outlook.office365.com (2a01:111:e400:855::51) with Microsoft SMTP Server (TLS) id 15.1.81.19 via Frontend Transport; Thu, 12 Feb 2015 22:04:32 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD004.mail.protection.outlook.com (10.1.14.158) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Thu, 12 Feb 2015 22:04:31 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 12 Feb 2015 14:04:30 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t1CM4TW20649; Thu, 12 Feb 2015 14:04:29 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id BAED1580A3; Thu, 12 Feb 2015 14:04:29 -0800 (PST) To: Ian Lepore Subject: Re: [RFC] Removin the old make In-Reply-To: <1423609456.80968.32.camel@freebsd.org> References: <20150210223854.GT29891@ivaldir.etoilebsd.net> <20150210224937.GE58387@eureka.lemis.com> <20150210225941.GU29891@ivaldir.etoilebsd.net> <1423609456.80968.32.camel@freebsd.org> Comments: In-reply-to: Ian Lepore message dated "Tue, 10 Feb 2015 16:04:16 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.0.3; nmh 1.3; GNU Emacs 22.3.1 Date: Thu, 12 Feb 2015 14:04:29 -0800 Message-ID: <15509.1423778669@chaos> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=sjg@juniper.net; freebsd.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(46102003)(57986006)(76176999)(62966003)(450100001)(106466001)(86362001)(117636001)(93886004)(110136001)(76506005)(558084003)(33716001)(105596002)(50986999)(77156002)(50226001)(47776003)(6806004)(2950100001)(92566002)(19580405001)(19580395003)(48376002)(77096005)(50466002)(87936001)(42262002)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB444; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB444; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:CO1PR05MB444; X-Forefront-PRVS: 0485417665 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB444; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Feb 2015 22:04:31.5501 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB444 Cc: Greg 'groggy' Lehey , arch@freebsd.org, Baptiste Daroussin , current@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 22:20:47 -0000 Ian Lepore wrote: > under bmake. It's especially annoying because :L is really common in > fmake and its meaning in bmake is all but useless. Actually it is very useful. eg. .if defined(NO_POSIX_SHELL) || ${type printf:L:sh:Mbuiltin} == "" From owner-freebsd-arch@FreeBSD.ORG Thu Feb 12 23:49:47 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9AAFAEE2; Thu, 12 Feb 2015 23:49:47 +0000 (UTC) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2D588F18; Thu, 12 Feb 2015 23:49:46 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBC8E7.dip0.t-ipconnect.de [93.203.200.231]) (authenticated bits=128) by slim.berklix.org (8.14.5/8.14.5) with ESMTP id t1CNrR3V088186; Fri, 13 Feb 2015 00:53:28 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id t1CNnW2R058294; Fri, 13 Feb 2015 00:49:32 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id t1CNnD43027915; Fri, 13 Feb 2015 00:49:32 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <201502122349.t1CNnD43027915@fire.js.berklix.net> To: Baptiste Daroussin Subject: Re: [RFC] Removin the old make From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Tue, 10 Feb 2015 23:38:54 +0100." <20150210223854.GT29891@ivaldir.etoilebsd.net> Date: Fri, 13 Feb 2015 00:49:13 +0100 Cc: arch@freebsd.org, current@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 23:49:47 -0000 > Hi, > > I would like to start using bmake only syntax on our infrastructure for tha= > t I > want to make sure noone is using the old make, so I plan to remove the old = .................................................^^^^^^^^^^^^^^^^^^ > make > =66rom base, I plan to do it by Feb 16th. > > Note that bmake is the default since FreeBSD 10. > FreeBSD 9.3 is also providing bmake (as bmake) on default installation. > > Best regards, > Bapt I don't know the difference, but it seems potentialy dangerous to remove old make without notice ? In FreeBSD-9.3 : bmake is not default, merely there -r-xr-xr-x 1 root wheel 518032 Nov 5 16:58 /usr/bin/bmake* -r-xr-xr-x 1 root wheel 453176 Nov 5 16:58 /usr/bin/make* & man make has No Warning people should migrate to bmake. FreeBSD-10.0 Has Only one /usr/bin/*make (& no make.old) & No warning that it's a new make called bmake or what if any differences might be from make in 9. cd ~ ; find . -type f -name Makefile | wc -l # 739 Use of FreeBSD is not merely to rebuild FreeBSD, but to support users who want to trust FreeBSD to provide predictable functional stability. Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Indent previous with "> ". Interleave reply paragraphs like a play script. Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. From owner-freebsd-arch@FreeBSD.ORG Fri Feb 13 00:19:40 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F92FCFB; Fri, 13 Feb 2015 00:19:40 +0000 (UTC) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AC6C6274; Fri, 13 Feb 2015 00:19:39 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id z11so12619194lbi.8; Thu, 12 Feb 2015 16:19:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Tk6+5q4jzi1kq5YcxZ53POnIOOmfu7I5bnQRi9lBwqU=; b=JM3ov/sSNow4BaFmY//tidNKogOAG6gNaGzl0oOZSYd96ttIVLlqtJxbo1C2wyokf7 pmKAGnfUtapdDTQTZQ0v7f9HBt8fWdqLSgVoPVVM8VNB4n3vRj1mzr8ZYxIwdCsdCPd6 jn1ChhzO5iBqySU6umYsSGIas4eqrQCNhfukgbIMoFZp1MJEPxAiQuwiR0EexRTjOckp of8T6+iU1oMNDAI2dSEzKk4Al3Y8yGM28NR6IjdM8ny2kqbW+JWwsTuHAHgcPQxw1LO8 O7NWgWyHH+CTK8KR8wKNyIIb864hwx+SAB/PfV54fWJjWmP8JEEbTifAb0/PQN2POMp8 1y9Q== MIME-Version: 1.0 X-Received: by 10.112.181.165 with SMTP id dx5mr5454175lbc.89.1423786777889; Thu, 12 Feb 2015 16:19:37 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.28.40 with HTTP; Thu, 12 Feb 2015 16:19:37 -0800 (PST) In-Reply-To: <201502122349.t1CNnD43027915@fire.js.berklix.net> References: <20150210223854.GT29891@ivaldir.etoilebsd.net> <201502122349.t1CNnD43027915@fire.js.berklix.net> Date: Thu, 12 Feb 2015 16:19:37 -0800 X-Google-Sender-Auth: 8_dbZbIAocFSj2NneiWM7tmNDDI Message-ID: Subject: Re: [RFC] Removin the old make From: Craig Rodrigues To: "Julian H. Stacey" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: arch@freebsd.org, Baptiste Daroussin , FreeBSD Current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 00:19:40 -0000 On Thu, Feb 12, 2015 at 3:49 PM, Julian H. Stacey wrote: > > In FreeBSD-9.3 : > bmake is not default, merely there > -r-xr-xr-x 1 root wheel 518032 Nov 5 16:58 /usr/bin/bmake* > -r-xr-xr-x 1 root wheel 453176 Nov 5 16:58 /usr/bin/make* > & man make has No Warning people should migrate to bmake. > > FreeBSD-10.0 > Has Only one /usr/bin/*make (& no make.old) > & No warning that it's a new make called bmake or what if any differences > might be from make in 9. > > Well, there was *some* warning in the release notes: https://www.freebsd.org/releases/9.3R/relnotes.html https://www.freebsd.org/releases/10.0R/relnotes.html Of course, the fmake/bmake changes are buried in a whole pile of other changes, so users may have found this easy to miss. It's hard to describe the impacts of changes like this, and have readable release notes. Oh well. :( -- Craig From owner-freebsd-arch@FreeBSD.ORG Fri Feb 13 00:25:02 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 670B4C1; Fri, 13 Feb 2015 00:25:02 +0000 (UTC) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E6FB336E; Fri, 13 Feb 2015 00:25:01 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id x13so13603634wgg.1; Thu, 12 Feb 2015 16:25:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=+ivukXEOSUD4jRUSlzSjiH67OBKuRa3NurW98m70G0M=; b=wv9PVetwrSnFrdMM3PbsGzu9IMYVeGMByakoijCt3e0zEusnIVYTT7xx6dxwESvTr/ wDMd68lzUJmz3pKoMByQNK1ypV6k7Fpr7rY4cpp6s6CnOeiPgz5F0UNM2Vq6xp+SnHiY spxa5Q7Jf/H5PGy0LQ3GISFDA6RIg5O2t3kWc6CXKmSxsS6zYIhm84HI/O/YbnaolHOi tJveUYJ666bY6LKv/gsNDa0b7kMYFaryiTglr4hQ9NV1WflnBXTF1YLYVTtsEams0rxY 28N+551QfiFNQbMvS5I4uqAHlQu+lVWLuucSX7FkZTFVNr5ejSufifQpT3DaHrK4WhVP +z6g== X-Received: by 10.180.10.131 with SMTP id i3mr11359557wib.54.1423787100377; Thu, 12 Feb 2015 16:25:00 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id dj4sm7737909wjc.13.2015.02.12.16.24.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Feb 2015 16:24:59 -0800 (PST) Sender: Baptiste Daroussin Date: Fri, 13 Feb 2015 01:24:56 +0100 From: Baptiste Daroussin To: "Julian H. Stacey" Subject: Re: [RFC] Removin the old make Message-ID: <20150213002456.GK29891@ivaldir.etoilebsd.net> References: <20150210223854.GT29891@ivaldir.etoilebsd.net> <201502122349.t1CNnD43027915@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VKLB3BcClAS4nArB" Content-Disposition: inline In-Reply-To: <201502122349.t1CNnD43027915@fire.js.berklix.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: arch@freebsd.org, current@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 00:25:02 -0000 --VKLB3BcClAS4nArB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 13, 2015 at 12:49:13AM +0100, Julian H. Stacey wrote: > > Hi, > >=20 > > I would like to start using bmake only syntax on our infrastructure for= tha=3D > > t I > > want to make sure noone is using the old make, so I plan to remove the = old =3D > .................................................^^^^^^^^^^^^^^^^^^ > > make > > =3D66rom base, I plan to do it by Feb 16th. > >=20 > > Note that bmake is the default since FreeBSD 10. > > FreeBSD 9.3 is also providing bmake (as bmake) on default installation. > >=20 > > Best regards, > > Bapt >=20 > I don't know the difference, but it seems potentialy dangerous to > remove old make without notice ? >=20 Old make was already removed in 10.x what remains is only the sources and t= hat is what I propose to remove from 11 (and only from 11) Best regards, Bapt --VKLB3BcClAS4nArB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTdRFgACgkQ8kTtMUmk6Ey6ewCffxD3H7f9ssYRxr0v4mWZJGlk XtcAnRpGs2VKWwj+9L73GlyLPyAv6h6t =jJzJ -----END PGP SIGNATURE----- --VKLB3BcClAS4nArB-- From owner-freebsd-arch@FreeBSD.ORG Fri Feb 13 00:47:30 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D00FB41; Fri, 13 Feb 2015 00:47:30 +0000 (UTC) Received: from pmta1.delivery4.ore.mailhop.org (pmta1.delivery4.ore.mailhop.org [54.191.151.194]) by mx1.freebsd.org (Postfix) with ESMTP id 3ACB47B4; Fri, 13 Feb 2015 00:47:29 +0000 (UTC) Received: from smtp4.ore.mailhop.org (172.31.18.134) by pmta1.delivery1.ore.mailhop.org id hrl4pm20r841; Fri, 13 Feb 2015 00:47:21 +0000 (envelope-from ) Received: from [73.34.117.227] (helo=ilsoft.org) by smtp4.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YM4Po-0003dX-7u; Fri, 13 Feb 2015 00:47:28 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t1D0lRTD001058; Thu, 12 Feb 2015 17:47:27 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX1+BcAd9SN1/fn9jkuYZ7v54 Message-ID: <1423788447.80968.123.camel@freebsd.org> Subject: Re: [RFC] Removin the old make From: Ian Lepore To: Baptiste Daroussin Date: Thu, 12 Feb 2015 17:47:27 -0700 In-Reply-To: <20150213002456.GK29891@ivaldir.etoilebsd.net> References: <20150210223854.GT29891@ivaldir.etoilebsd.net> <201502122349.t1CNnD43027915@fire.js.berklix.net> <20150213002456.GK29891@ivaldir.etoilebsd.net> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, "Julian H. Stacey" , current@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 00:47:30 -0000 On Fri, 2015-02-13 at 01:24 +0100, Baptiste Daroussin wrote: > On Fri, Feb 13, 2015 at 12:49:13AM +0100, Julian H. Stacey wrote: > > > Hi, > > > > > > I would like to start using bmake only syntax on our infrastructure for tha= > > > t I > > > want to make sure noone is using the old make, so I plan to remove the old = > > .................................................^^^^^^^^^^^^^^^^^^ > > > make > > > =66rom base, I plan to do it by Feb 16th. > > > > > > Note that bmake is the default since FreeBSD 10. > > > FreeBSD 9.3 is also providing bmake (as bmake) on default installation. > > > > > > Best regards, > > > Bapt > > > > I don't know the difference, but it seems potentialy dangerous to > > remove old make without notice ? > > > Old make was already removed in 10.x what remains is only the sources and that > is what I propose to remove from 11 (and only from 11) > > Best regards, > Bapt fmake exists as a port too, doesn't it? That's what I vaguely remember as the plan... bmake available in 9, it's the default in 10 but fmake source is still around, and then in 11 fmake is gone from base but available as a port. -- Ian From owner-freebsd-arch@FreeBSD.ORG Fri Feb 13 01:01:50 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2476289; Fri, 13 Feb 2015 01:01:50 +0000 (UTC) Received: from udns.ultimatedns.net (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A004B949; Fri, 13 Feb 2015 01:01:49 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t1D10TGV046986; Thu, 12 Feb 2015 17:00:29 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Baptiste Daroussin , Ian Lepore In-Reply-To: <1423788447.80968.123.camel@freebsd.org> References: <20150210223854.GT29891@ivaldir.etoilebsd.net> <201502122349.t1CNnD43027915@fire.js.berklix.net> <20150213002456.GK29891@ivaldir.etoilebsd.net>, <1423788447.80968.123.camel@freebsd.org> From: "Chris H" Subject: Re: [RFC] Removin the old make Date: Thu, 12 Feb 2015 17:00:29 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <88e1e09e1f329b88da8f2fa5bde6005e@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: arch@freebsd.org, "Julian H. Stacey" , current@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 01:01:50 -0000 On Thu, 12 Feb 2015 17:47:27 -0700 Ian Lepore wrote > On Fri, 2015-02-13 at 01:24 +0100, Baptiste Daroussin wrote: > > On Fri, Feb 13, 2015 at 12:49:13AM +0100, Julian H. Stacey wrote: > > > > Hi, > > > > > > > > I would like to start using bmake only syntax on our infrastructure for > > > tha= > t I > > > > want to make sure noone is using the old make, so I plan to remove the > > > old = .................................................^^^^^^^^^^^^^^^^^^ > > > > make > > > > =66rom base, I plan to do it by Feb 16th. > > > > > > > > Note that bmake is the default since FreeBSD 10. > > > > FreeBSD 9.3 is also providing bmake (as bmake) on default installation. > > > > > > > > Best regards, > > > > Bapt > > > > > > I don't know the difference, but it seems potentialy dangerous to > > > remove old make without notice ? > > > > > Old make was already removed in 10.x what remains is only the sources and > > that is what I propose to remove from 11 (and only from 11) > > > > Best regards, > > Bapt > > fmake exists as a port too, doesn't it? That's what I vaguely remember > as the plan... bmake available in 9, it's the default in 10 but fmake > source is still around, and then in 11 fmake is gone from base but > available as a port. If that's the case. It all hardly seems worth an announcement. Nothing's lost, and everyone wins. :) --Chris > > -- Ian > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Fri Feb 13 08:46:11 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BAA98C31; Fri, 13 Feb 2015 08:46:11 +0000 (UTC) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 59C3EE13; Fri, 13 Feb 2015 08:46:11 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id u56so15125055wes.10; Fri, 13 Feb 2015 00:46:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=gCjT1o1sgtT0LLGN9Gw57oMpoga7QHqAmhloJZcvyws=; b=G+UBO2x2Ob4P+kP6G+BE9Yhj1Tb6uPkv/x8cRd/rqKBFcUXVlVRrHSV6cFHoWXKqb9 RP8OtN3TZ84bZTh26H49p16ExyhZCAnxXeZzyWhja41HFBRDGH7iaeAMFxEx2su4fDPw sKvc85KHQA1+flib0ptXqWbsNP4A0bLOjJWu0DC4BkKHJItK75Dswv1FY4VYWqk1l4ZM HGFns+za7DPar1y988i/bTVVSurLiLpeAyvmfMt01nQECduFU6/iA9VGl6jqlbxDuG/K 2Pc8FR9zhtPZmEVJjR3LuuitSAG7qKpgoihpixWARzhrN4apwrxWnVA6rdqLq5A7Jlrr ZVhw== X-Received: by 10.194.23.39 with SMTP id j7mr16343722wjf.9.1423817169736; Fri, 13 Feb 2015 00:46:09 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id do1sm2002147wib.3.2015.02.13.00.46.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Feb 2015 00:46:08 -0800 (PST) Sender: Baptiste Daroussin Date: Fri, 13 Feb 2015 09:46:06 +0100 From: Baptiste Daroussin To: Ian Lepore Subject: Re: [RFC] Removin the old make Message-ID: <20150213084606.GM29891@ivaldir.etoilebsd.net> References: <20150210223854.GT29891@ivaldir.etoilebsd.net> <201502122349.t1CNnD43027915@fire.js.berklix.net> <20150213002456.GK29891@ivaldir.etoilebsd.net> <1423788447.80968.123.camel@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MqkwUViToTQK+HjE" Content-Disposition: inline In-Reply-To: <1423788447.80968.123.camel@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: arch@freebsd.org, "Julian H. Stacey" , current@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 08:46:11 -0000 --MqkwUViToTQK+HjE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 12, 2015 at 05:47:27PM -0700, Ian Lepore wrote: > On Fri, 2015-02-13 at 01:24 +0100, Baptiste Daroussin wrote: > > On Fri, Feb 13, 2015 at 12:49:13AM +0100, Julian H. Stacey wrote: > > > > Hi, > > > >=20 > > > > I would like to start using bmake only syntax on our infrastructure= for tha=3D > > > > t I > > > > want to make sure noone is using the old make, so I plan to remove = the old =3D > > > .................................................^^^^^^^^^^^^^^^^^^ > > > > make > > > > =3D66rom base, I plan to do it by Feb 16th. > > > >=20 > > > > Note that bmake is the default since FreeBSD 10. > > > > FreeBSD 9.3 is also providing bmake (as bmake) on default installat= ion. > > > >=20 > > > > Best regards, > > > > Bapt > > >=20 > > > I don't know the difference, but it seems potentialy dangerous to > > > remove old make without notice ? > > >=20 > > Old make was already removed in 10.x what remains is only the sources a= nd that > > is what I propose to remove from 11 (and only from 11) > >=20 > > Best regards, > > Bapt >=20 > fmake exists as a port too, doesn't it? That's what I vaguely remember > as the plan... bmake available in 9, it's the default in 10 but fmake > source is still around, and then in 11 fmake is gone from base but > available as a port. >=20 Yes it is in port for sure. Bapt --MqkwUViToTQK+HjE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTduc4ACgkQ8kTtMUmk6EzrIQCeMb2V6jynVUmS41XXqYyj9gke 65YAniw8ww4DpS4O47zueKz8QDa4vHmc =TPb/ -----END PGP SIGNATURE----- --MqkwUViToTQK+HjE--