Warner Losh wrote:
> > Officially this code is on the 12.0 target path, it needs
> > to be in the tree sooner where many eyes can work on it.
> >
>
> I concur here. Let's give it until 12 to get sorted. If it's mostly sorted
> by then, we're good.
> If not we can have the discussion then.
> There
On Thu, Jun 21, 2018 at 3:10 PM, Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:
> ...
>
> > > Hi,
> > >
> > > While the code is out of HEAD, it can be posted to a github branch
> > > (or
> > > a projects/ branch if you prefer SVN) for people to try.
> > >
> > > Best regards,
> > > Conra
...
> > Hi,
> >
> > While the code is out of HEAD, it can be posted to a github branch
> > (or
> > a projects/ branch if you prefer SVN) for people to try.
> >
> > Best regards,
> > Conrad
> >
>
> Yeah, put it on a branch where it'll get ignored for another two years.
>
> If this code had bee
On Thu, 2018-06-21 at 19:02 +, Mark Linimon wrote:
> On Thu, Jun 21, 2018 at 12:33:26PM -0600, Ian Lepore wrote:
> >
> > Hiding work in patchsets and reviews and alternate branches and
> > other
> > shadowy places because it's not perfect
> I do not consider bugzilla and phabricator to be "sha
On Thu, Jun 21, 2018 at 12:33:26PM -0600, Ian Lepore wrote:
> Hiding work in patchsets and reviews and alternate branches and other
> shadowy places because it's not perfect
I do not consider bugzilla and phabricator to be "shadowy places";
therefore, I reject this argument.
Although I don't have
On Thu, 2018-06-21 at 11:13 -0700, Conrad Meyer wrote:
> On Thu, Jun 21, 2018 at 9:51 AM, Stephen Kiernan om> wrote:
> >
> > On Wed, Jun 20, 2018 at 10:36 PM, Eitan Adler > > wrote:
> > >
> > >
> > > On 19 June 2018 at 20:08, Eitan Adler
> > > wrote:
> > > >
> > > > On 19 June 2018 at 18:08,
On Thu, Jun 21, 2018 at 9:51 AM, Stephen Kiernan wrote:
> On Wed, Jun 20, 2018 at 10:36 PM, Eitan Adler wrote:
>>
>> On 19 June 2018 at 20:08, Eitan Adler wrote:
>> > On 19 June 2018 at 18:08, Stephen J. Kiernan wrote:
>> >> Added: head/sbin/veriexecctl/Makefile
>> >>
>> >>
On Wed, Jun 20, 2018 at 10:36 PM, Eitan Adler wrote:
> On 19 June 2018 at 20:08, Eitan Adler wrote:
> > On 19 June 2018 at 18:08, Stephen J. Kiernan wrote:
> >> Added: head/sbin/veriexecctl/Makefile
> >>
> ==
> >> ---
On 19 June 2018 at 20:08, Eitan Adler wrote:
> On 19 June 2018 at 18:08, Stephen J. Kiernan wrote:
>> Added: head/sbin/veriexecctl/Makefile
>> ==
>> --- /dev/null 00:00:00 1970 (empty, because file is newly added)
>>
(Apologies to cem@ for the duplicate in his inbox, Gmail decided to not
reply-all in my reply.)
On Wed, Jun 20, 2018 at 1:07 PM, Conrad Meyer wrote:
> Hi Jon,
>
> On Wed, Jun 20, 2018 at 11:58 AM, Jonathan Anderson
> wrote:
> > On 20 Jun 2018, at 15:32, Jonathan T. Looney wrote:
> >> My reasoni
Conrad Meyer wrote:
> The signing of manifests does not exist in the patch series committed.
Nor will it, the singing of manifests is a build thing.
But as I mentioned earlier I think the loader verification code can be
leveraged for a verifying userland veriexec tool similar to that in
Junos.
Xin LI wrote:
> I do agree with others that SHA-1 support should not be included
It can certainly be disabled by default.
> (unless I have missed something, but I think firmware integrity check
> counts as a "Digital signature" verification, according to SP 800-131A
A "Digital signature" verifi
Hi Jon,
On Wed, Jun 20, 2018 at 11:58 AM, Jonathan Anderson
wrote:
> On 20 Jun 2018, at 15:32, Jonathan T. Looney wrote:
>> My reasoning
>> was fairly simple: when a review has been open for over a year with no
>> action, it seems like the submitter should be able to commit it without
>> waiting
On 20 Jun 2018, at 15:32, Jonathan T. Looney wrote:
On Wed, Jun 20, 2018 at 9:49 AM Stephen Kiernan
wrote:
And I was working on those sets of changes, when work and family
didn't
steal away time. I was told that some discussion happened at BSDCan
this
year in such that veriexec should go in
On Wed, Jun 20, 2018 at 10:58 AM Jonathan T. Looney wrote:
>
> On Tue, Jun 19, 2018 at 8:34 PM Conrad Meyer wrote:
>>
>> Please revert this patchset. It's not ready.
>
>
> I'm not sure I understand the need to revert the patches. They may need some
> refinement, but they also do provide some fu
On Wed, Jun 20, 2018 at 9:49 AM Stephen Kiernan
wrote:
> And I was working on those sets of changes, when work and family didn't
> steal away time. I was told that some discussion happened at BSDCan this
> year in such that veriexec should go in as-is so it would be there, which
is why
> the commi
On Tue, Jun 19, 2018 at 8:34 PM Conrad Meyer wrote:
> Please revert this patchset. It's not ready.
>
I'm not sure I understand the need to revert the patches. They may need
some refinement, but they also do provide some functionality upon which you
can build the tooling that Simon discussed.
U
Hi Simon,
Jonathan points out some of my comments were more acerbic than
necessary. I apologize for that. I'd like to try to rephrase them in
a more clear way.
On Wed, Jun 20, 2018 at 8:43 AM, Conrad Meyer wrote:
> On Tue, Jun 19, 2018 at 11:21 PM, Simon J. Gerraty wrote:
>> As I mentioned in
On Wed, Jun 20, 2018 at 9:30 AM, Conrad Meyer wrote:
>
> Please look at the actual code size and layout of the sha1 support
> module and tell me that is a burden for Juniper to maintain in their
> downstream tree, rather than just getting angry about the suggestion
> we don't introduce novel, inse
On Wed, 2018-06-20 at 09:30 -0700, Conrad Meyer wrote:
> Ian,
>
> On Wed, Jun 20, 2018 at 8:58 AM, Ian Lepore wrote:
> >
> > And I request exactly the opposite: reject the complaining of people
> > who think all the world is a 256-core 5ghz server
> First: no need to be so rude to other committe
Ian,
On Wed, Jun 20, 2018 at 8:58 AM, Ian Lepore wrote:
> And I request exactly the opposite: reject the complaining of people
> who think all the world is a 256-core 5ghz server
First: no need to be so rude to other committers. The hyperbole
doesn't help anyone and doesn't help communicate you
I want to preface this by saying: this discussion should be happening
in either arch@ or phabricator, after the patch series was temporarily
reverted pending necessary improvements. I have asked for the series
to be reverted and am still waiting on that.
I am happy to promise to respond promptly
On Wed, 2018-06-20 at 08:45 -0700, Conrad Meyer wrote:
> You can keep these poor security modes in your downstream product if
> you want, but don't put them in the tree.
>
And I request exactly the opposite: reject the complaining of people
who think all the world is a 256-core 5ghz server and le
You can keep these poor security modes in your downstream product if
you want, but don't put them in the tree.
On Wed, Jun 20, 2018 at 8:28 AM, Simon J. Gerraty wrote:
> Benjamin Kaduk wrote:
>> With all due respect, NIST is hardly the sole authority on this topic.
>
> True, unless of course you
Cy Schubert wrote:
> > The signing of manifests is external. The veriexecctl tool is I assume
> > a straight copy of what's in NetBSD (I've not looked at it in at least a
> > decade).
>
> If this is correct, should it not be imported into the vendor branches
> first?
>
> What are the criteria
Benjamin Kaduk wrote:
> With all due respect, NIST is hardly the sole authority on this topic.
True, unless of course you sell to US govt.
> With my IETF Security Area Director hat on, any greenfield proposal coming
> in
> to the IESG that included sha1 support would get extremely strong pushbac
On Wed, Jun 20, 2018, 6:42 AM Cy Schubert wrote:
> In message <96021.1529475...@kaos.jnpr.net>, "Simon J. Gerraty" writes:
> > Conrad Meyer wrote:
> > > First and foremost: nothing is actually signed, anywhere. The
> >
> > The signing of manifests is external. The veriexecctl tool is I assume
Simon J. Gerraty wrote:
> > - Maybe sign the source-of-trust file
>
> We do. As noted above, we cannot upstream that until FreeBSD has
> suitable signing infra.
It occurred to me, that since I'll be upstreaming a library that
uses BearSSL to do the necessary manifest verification for the loader
In message <96021.1529475...@kaos.jnpr.net>, "Simon J. Gerraty" writes:
> Conrad Meyer wrote:
> > First and foremost: nothing is actually signed, anywhere. The
>
> The signing of manifests is external. The veriexecctl tool is I assume
> a straight copy of what's in NetBSD (I've not looked at it
On Wed, Jun 20, 2018 at 1:21 AM, Simon J. Gerraty wrote:
> Conrad Meyer wrote:
>
> > There's absolutely no reason to use sha1 or ripemd in new designs.
> > These should be removed.
>
> Sorry I disagree - not with ripem (we never supported that or any of the
> non-NIST approved hashes), but sha1
On Tue, Jun 19, 2018 at 11:21 PM, Simon J. Gerraty wrote:
> Conrad Meyer wrote:
>
> > As a corollary to the above, the name "signature file" is used
> > repeatedly in the code, which is misleading. The file contains hashes
> > (digests), not signatures (MACs). The file itself is unsigned.
> >
Conrad Meyer wrote:
> First and foremost: nothing is actually signed, anywhere. The
The signing of manifests is external. The veriexecctl tool is I assume
a straight copy of what's in NetBSD (I've not looked at it in at least a
decade).
A veriexec loader that leverages signed manifests require
In message
, Conrad Meyer writes:
> On Tue, Jun 19, 2018 at 6:08 PM, Stephen J. Kiernan wrot
> e:
> > Author: stevek
> > Date: Wed Jun 20 01:08:54 2018
> > New Revision: 335402
> > URL: https://svnweb.freebsd.org/changeset/base/335402
> >
> > Log:
> > This application (veriexecctl) handles read
I forgot to mention that the kernel code also introduces severe
performance problems due to really pessimal data structures, small IO
sizes, and problematic locking.
Again: please revert and proceed through a round or two of design review.
Thank you,
Conrad
On Tue, Jun 19, 2018 at 8:33 PM, Conra
On Tue, Jun 19, 2018 at 6:08 PM, Stephen J. Kiernan wrote:
> Author: stevek
> Date: Wed Jun 20 01:08:54 2018
> New Revision: 335402
> URL: https://svnweb.freebsd.org/changeset/base/335402
>
> Log:
> This application (veriexecctl) handles reading a fingerprints file
Hi,
This patchset needed des
On 19 June 2018 at 18:08, Stephen J. Kiernan wrote:
> Added: head/sbin/veriexecctl/Makefile
> ==
> --- /dev/null 00:00:00 1970 (empty, because file is newly added)
> +++ head/sbin/veriexecctl/Makefile Wed Jun 20 0
Author: stevek
Date: Wed Jun 20 01:08:54 2018
New Revision: 335402
URL: https://svnweb.freebsd.org/changeset/base/335402
Log:
This application (veriexecctl) handles reading a fingerprints file
containing paths, fingerprints, and optional option flags which in turn
get pushed into the MAC/ver
37 matches
Mail list logo
