Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

[Ian Denhardt]

Cute. I think we're better off without it though; the use cases I can
think of for "generic booleans" are all way too clever.

FWIW, the uses of "generic booleans" I've seen in the wild don't
actually work with your proposal, because they really do need to
overload `and` and `or`, not just `not`. But this is getting off into
the weeds.

Quoting Eric Raymond (2018-10-16 00:17:19)
>On Monday, October 15, 2018 at 11:32:23 PM UTC-4, Eric Raymond wrote:
>
>Fair enough.�  I am completely willing to discard the possibility of
>overloading && and ||
>
>A little thought showed me that this is not required.
>The straightforward way to write the contract of "!" would be that it
>is a monadic function of any type returning true if the operand is the
>zero value of that type and false otherwise.�  It follows that for
>types with "implements !" the expression a && b expands to this:
>if !!a {return !!a} else {return !!b}
>If we want to be more Pythonic and remove the requirement that it
>return bool
>if !!a {return a} else {return b}
>provided a and b are the same type.
>
>--
>You received this message because you are subscribed to the Google
>Groups "golang-nuts" group.
>To unsubscribe from this group and stop receiving emails from it, send
>an email to [1]golang-nuts+unsubscr...@googlegroups.com.
>For more options, visit [2]https://groups.google.com/d/optout.
>
> Verweise
>
>1. mailto:golang-nuts+unsubscr...@googlegroups.com
>2. https://groups.google.com/d/optout

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics: an unwelcome conclusion and a proposal

[Beoran]

Well, you could certainly implement min or max generically without operators in 
contracts if you use a wrapper type for primitives and pointers. A bit more 
verbose perhaps, but that is also how it is now.

I can only speak for myself and say that I would not be disappointed at all 
with such simple contracts. IMHO generics could just be the compile time 
equivalent of interfaces, an that would be largely sufficient for me. 

Then again, I guess people coming from other languages like D or C++ would 
expect generics to work with operators. So I can see where Ian is coming from. 

But on the third hand, Go is a language that doesn't add features just because 
people expect or like them. The basic design of Go is to have only features for 
which the benefits outweigh the complexity cost. Seeing that operators in 
contracts are complex and not strictly needed, I feel we could do without.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Understanding the doc (why can't I?)

[Dan Kortschak]

¡left off the Len method!

type Swapper interface {
// Swap swaps the elements i and j.
Swap(i, j int)

// Len returns the number of elements that may be swapped.
Len() int
}

func Shuffle(s Swapper)

On Tue, 2018-10-16 at 03:46 +, Dan Kortschak wrote:
> type Swapper interface {
> // Swap swaps the elements i and j.
> Swap(i, j int)
> }
>
> func Shuffle(s Swapper)
>
> On Mon, 2018-10-15 at 19:58 -0700, Bakul Shah wrote:
> >
> > On Mon, 15 Oct 2018 20:39:11 -0600 andrey mirtchovski  > gm
> > ail.com> wrote:
> > >
> > >
> > > >
> > > >
> > > > May be it ought to be called FYShuffle?
> > > then we'ld have to rename it if we switched the algorithm (which
> > > has
> > > happened once for sort.Sort already). that's not what go is about
> > > :)
> > Unlikely :-)
> >
> > The following is much less obscure.
> >
> > func Shuffle(slice inteface{})
> >
> > & might have more more sense. e.g.
> >
> > var cards []card
> > ...
> > rand.Shuffle(cards)
> >
> >
> > The current Shuffle is confusing. May be because it has a
> > somewhat clumsy interface.
> >
> > >
> > >
> > > maybe you're advocating for implementing a Shuffle interface,
> > > which
> > > brings us round about to where we are right now :)
> > I'll shuffle off now

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

[Eric Raymond]

On Monday, October 15, 2018 at 11:59:44 PM UTC-4, Ian Denhardt wrote:
>
> I'm not in love with the inconsistency, and expect it to cause some 
> confusion with newbies, but I'd have to use it to see how big of a 
> footgun it is in practice. There are certainly worse ideas. 
>

Yes.  If that's the biggest objection anyone comes up with, I think we win 
by a long country mile  over complicated contract-declaration proposals 
where it's difficult to even see where the edge cases might be.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics: an unwelcome conclusion and a proposal

[Eric Raymond]

On Tuesday, October 16, 2018 at 12:16:16 AM UTC-4, Beoran wrote:
>
>  For niw, I don't see what complelling benefits allowing operators in 
> generic contracts would bring.
>

Consider Ian Lance Taylor's smoke test for generics.  It is: can we 
implement min() and max() on a generic type. 

What he's getting at is that a generic-type system that doesn't have enough 
contract-making strength for this is going to disappoint a lot of the 
people who report wanting generics. I agree.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

[Eric Raymond]

On Monday, October 15, 2018 at 11:32:23 PM UTC-4, Eric Raymond wrote:
>
> Fair enough.  I am completely willing to discard the possibility of 
> overloading && and ||
>

A little thought showed me that this is not required.

The straightforward way to write the contract of "!" would be that it is a 
monadic function of any type returning true if the operand is the zero 
value of that type and false otherwise.  It follows that for types with 
"implements !" the expression a && b expands to this:

if !!a {return !!a} else {return !!b}

If we want to be more Pythonic and remove the requirement that it return 
bool

if !!a {return a} else {return b}

provided a and b are the same type.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Generics: an unwelcome conclusion and a proposal

[Beoran]

I agree that operators in contracts and the proposed generics don't seem to 
mesh well. Your proposal would enable the use of operators in interfaces in an 
easy way.


However, personally I think that perhaps we don't need operators at all. 
Suppose I was to implement a generic btrie or such today in Go1. How would I do 
it? I would use an interface for the data in nodes like this:

BtrieData interface {
Equals(data BtrieData) bool
Less(data BtrieData) bool
AssignTo(target *BtrieData) error
}

No operators, just member functions.
The only downside to this is for primitive types which will need a wrapper 
types. Implementing such a wrapper type is pretty easy, and with generics, the 
compiler could likely optimize generic wrapper types. 

Seeing how complex the interaction between generics and operators would become, 
I would simply drop them an use interfaces as they are now as the contract 
type. For niw, I don't see what complelling benefits allowing operators in 
generic contracts would bring.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

[Ian Denhardt]

Quoting Eric Raymond (2018-10-15 23:32:22)

>Fair enough.  I am completely willing to discard the possibility of
>overloading && and || and almost any other operator that doesn't behave
>like a function, because I think we get a rich enough set of contracts
>from those that do.  As I implied in my proposal, I think what people
>really want from contacts is relationals and some operator algebra.

+1. == is the sticking point.

> That is to forbid "implements" methods on pointer types at compile
> time.

The other bit of this, that I think is worth making explicit is that
normally If you have a method on a type T, you can also call that method
on a value of type *T. For this to work you'd also have to have == be an
exception to that rule, where == on a type of the form *T is always pointer
equality, regardless of what == means on T.

I'm not in love with the inconsistency, and expect it to cause some
confusion with newbies, but I'd have to use it to see how big of a
footgun it is in practice. There are certainly worse ideas.

> I can't think of a use case for such overloads that isn't overly clever
> to the point of crazy. I am more than willing to chop that off to preserve
> the simplicity and transparency of the cases where "implements" is legal.

Agree, my only concern is as mentioned above.

It's also worth noting that you can always wrap the pointer in a new type
if you want to define operators on it.

-Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Understanding the doc (why can't I?)

[Bakul Shah]

On Mon, 15 Oct 2018 21:29:07 -0600 andrey mirtchovski  
wrote:
> > Unlikely :-)
> >
> > The following is much less obscure.
> >
> > func Shuffle(slice inteface{})
> >
> > & might have more more sense. e.g.
> >
> > var cards []card
> > ...
> > rand.Shuffle(cards)
>
> you've now restricted Shuffle to "shuffling" only slices. and it has

The current Shuffle is calling its func argument with indices
which make most sense for slices! What other use has it been
put to?

> to examine interface{} to determine if it's "shuffle-able". calling
> Shuffle(nil) in your example would still not do anything (which is one
> of the original issues of OP).  i posit that the current shuffle makes
> good sense given the language. metaphysics notwithstanding.

No, the interface will be examined to find a swap interface.
Something like

rv := reflect.ValueOf(slice)
swap = reflect.Swapper(slice)
Shuffle(rv.Len(), swap) // current Shuffle

The same as in Sort.Slice().

All in the name of a little bit of efficiency.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Understanding the doc (why can't I?)

[Dan Kortschak]

type Swapper interface {
// Swap swaps the elements i and j.
Swap(i, j int)
}

func Shuffle(s Swapper)

On Mon, 2018-10-15 at 19:58 -0700, Bakul Shah wrote:
> On Mon, 15 Oct 2018 20:39:11 -0600 andrey mirtchovski  ail.com> wrote:
> >
> > >
> > > May be it ought to be called FYShuffle?
> > then we'ld have to rename it if we switched the algorithm (which
> > has
> > happened once for sort.Sort already). that's not what go is about
> > :)
> Unlikely :-)
>
> The following is much less obscure.
>
> func Shuffle(slice inteface{})
>
> & might have more more sense. e.g.
>
> var cards []card
> ...
> rand.Shuffle(cards)
>
>
> The current Shuffle is confusing. May be because it has a
> somewhat clumsy interface.
>
> >
> > maybe you're advocating for implementing a Shuffle interface, which
> > brings us round about to where we are right now :)
> I'll shuffle off now

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

[Eric Raymond]

On Monday, October 15, 2018 at 11:02:18 PM UTC-4, Ian Denhardt wrote:
>
>
> There are other operators in the language that don't behave like 
> functions or methods (e.g. boolean operators like && and ||, which 
> short-circut), but the rest of them are things that don't have gobs of 
> use cases for overriding anyway, so it's easy to just say "you can't 
> override those." I don't think we can credibly call operator overloading 
> a solution if you can't abstract over ==. 
>

Fair enough.  I am completely willing to discard the possibility of 
overloading && and || and almost any other operator that doesn't behave 
like a function, because I think we get a rich enough set of contracts from 
those that do.  As I implied in my proposal, I think what people really 
want from contacts is relationals and some operator algebra.

But your objection about pointer types is sound.  And there is a simple 
solution to it. That is to forbid "implements" methods on pointer types at 
compile time.

I can't think of a use case for such overloads that isn't overly clever to 
the point of crazy.  I am more than willing to chop that off to preserve 
the simplicity and transparency of the cases where "implements" is legal.
 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Understanding the doc (why can't I?)

[andrey mirtchovski]

> Unlikely :-)
>
> The following is much less obscure.
>
> func Shuffle(slice inteface{})
>
> & might have more more sense. e.g.
>
> var cards []card
> ...
> rand.Shuffle(cards)

you've now restricted Shuffle to "shuffling" only slices. and it has
to examine interface{} to determine if it's "shuffle-able". calling
Shuffle(nil) in your example would still not do anything (which is one
of the original issues of OP).  i posit that the current shuffle makes
good sense given the language. metaphysics notwithstanding.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Understanding the doc (why can't I?)

[1955neilh]

Oh well! Bakul - thank you for that little bit of affirmation. I feel 
better now :-)
 

> The current Shuffle is confusing. May be because it has a 

somewhat clumsy interface.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

[Ian Denhardt]

Quoting Eric Raymond (2018-10-15 22:24:50)

>The simplest and most effective way to solve the generics problem is to
>embrace operator overloading and the kind of magic method designations
>that go with it.

This matches my intuition as well, though see below.

>Can it even possibly be simpler than this? What, if anything, am I
>missing?

There are a couple of things I could bikeshed, but instead I'll raise a
deeper problem, which none of the operator-overloading designs I've seen
(or thought of) have had an answer for, and I think *needs* to be solved
for this to work: The semantics of `==` in Go cannot be understood as a
method or function.

In particular, there is a restriction in the go spec that says you can't
implement methods with the same name on both T and *T. However, `==` is
defined on pointers, and always computes pointer identity, whereas it
may (almost certainly will) do something different on the type that the
pointer points to.

There are other operators in the language that don't behave like
functions or methods (e.g. boolean operators like && and ||, which
short-circut), but the rest of them are things that don't have gobs of
use cases for overriding anyway, so it's easy to just say "you can't
override those." I don't think we can credibly call operator overloading
a solution if you can't abstract over ==.

Breaking backwards compatibility opens up some options, but I still
haven't been able to come up with a solution that has a credible upgrade
path.

I've mentioned this when it's come up in a couple of other threads, but
not everybody reads every rabbit-hole conversation about generics...

-Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Understanding the doc (why can't I?)

[Bakul Shah]

On Mon, 15 Oct 2018 20:39:11 -0600 andrey mirtchovski  
wrote:
> > May be it ought to be called FYShuffle?
>
> then we'ld have to rename it if we switched the algorithm (which has
> happened once for sort.Sort already). that's not what go is about :)

Unlikely :-)

The following is much less obscure.

func Shuffle(slice inteface{}) 

& might have more more sense. e.g.

var cards []card
...
rand.Shuffle(cards)


The current Shuffle is confusing. May be because it has a
somewhat clumsy interface.

> maybe you're advocating for implementing a Shuffle interface, which
> brings us round about to where we are right now :)

I'll shuffle off now

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Understanding the doc (why can't I?)

[andrey mirtchovski]

> May be it ought to be called FYShuffle?

then we'ld have to rename it if we switched the algorithm (which has
happened once for sort.Sort already). that's not what go is about :)

maybe you're advocating for implementing a Shuffle interface, which
brings us round about to where we are right now :)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

[robert engels]

Also, what maybe I wasn’t clear here - that is the ‘verification is local - say 
a local app’, if the machine has been compromised - the binary can be edited to 
remove the security check - no need to even have the dongle - thus the 
requirement for an external resource being protected.

> On Oct 15, 2018, at 7:12 PM, Christopher Nielsen  wrote:
> 
> On Mon, Oct 15, 2018 at 4:33 PM robert engels  wrote:
>> 
>> To clarify, this is for a hardware device that protects a local resource - a 
>> network based protocol that challenges the device for access is a different 
>> story, and yes, when properly implemented is secure (unless someone steals 
>> your device! - which is why it is usually password + device, and then you 
>> are back to the same problem of compromising passwords when root access has 
>> been compromised).
> 
> This statement indicates to me you don't understand how hardware
> security tokens work. It doesn't matter if you have root access. You
> cannot obtain key material from it. If you lose it, you lose the set
> of keys on it. That's it. Revoke them and issue new ones using your
> root cert/key that never touches a networked system and lives in a
> safe.
> 
> -- 
> Christopher Nielsen
> "They who can give up essential liberty for temporary safety, deserve
> neither liberty nor safety." --Benjamin Franklin
> "The tree of liberty must be refreshed from time to time with the
> blood of patriots & tyrants." --Thomas Jefferson
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Generics: an unwelcome conclusion and a proposal

[Eric Raymond]

Recent discussion of possible generics designs has forced me to a 
conclusion I'm not happy with, because it requires a feature-cluster that I 
thought I was glad  to be leaving behind in Python.  That is this:

The simplest and most effective way to solve the generics problem is to 
embrace operator overloading and the kind of magic method designations that 
go with it.

I'm still not a big fan of operator overloading as a surface feature of the 
language.  I think the arguments that it encourages overly clever 
one-liners are sound. My argument is not in favor of that. Rather, after 
reviewing all the design strawmen I have seen, I see no way to declare 
contracts for generics that is (a) as simple, and (this is a really 
important point brought out in a recent post) maintains unification with 
primitive types.

In fact, more and more as I look at the proposals that have failed to catch 
fire I see them as clever but doomed attempts to evade operator overloading 
because most people did not want that camel's nose in the tent.  As a 
matter of cold fact I don't either, but I am forced to the conclusion that 
in the portion of design space we can easily reach from Go 1, operator 
overloading and contracts are more joined at the hip than anyone - 
including me - has been willing to face up to now.  I therefore propose 
that we embrace the suck and limit the complexity load on the rest of the 
language as much as possible. 

Here's a stupid-simple system for describing generic contracts with just 
one new keyword: "implements", having  a single argument which is a token 
that may occur as an operator in expressions.   Here is what it would look 
like:

type Sortable interface { 
implements <
}

type MySortable struct {
name string
sortkey id
}

func (r MySortable) LessThan (s MySortable) bool implements < {
return r.sortkey < s.sortkey
}

Because MySortable has a method that "imnplements <", it satisfies the 
Sortable interface.

Each eligible operator has an implied generic signature.  For example is we 
use s and t as generic argument placeholders, that of < is 
s.(T).func(t T) bool.   That of + would be s.(T).func(t T) T.  It would be 
a compile-time error for an "implements"  method not to match the signature 
template of its operator as it applies to basic types.

The general insight this leverages is that every primitive-type operator 
implies a description of a contract *without adding any additional 
complexity to the language*.

Notice that we have evaded the methods themselves needing to have magic 
names.  The only declaration of contract and overloading is the 
"implements" clause.

This passes Ian's smoke test. That is, it is easy to see how to implement 
min() and max() on generics under this system.

By being able to define relationals  and + or * as a composition operator 
for algebras on user-defined types I think we solve a huge part of the 
generic contracts problem.  At the cost of adding only one new construct to 
the language, and one that is easy to describe and understand.  (Because 
the heavy lifting is done by well-established expectations about the 
behavior of primitive types.)

Perhaps I risk overreaching, for I am relatively new to the language, but 
it seems to me that the simplicity and orthogonality of this proposal are 
very much in the spirit of Go. Enough to that the side effect of 
overloading as a surface syntactic feature is - if grudgingly - forgivable.

Can it even possibly be simpler than this? What, if anything, am I missing?


 


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

[robert engels]

That is not true. If you lose the key, anyone else can use the device - which 
is why there is usually an additional requirement beyond the hardware key - I 
am referring to hardware dongles given to users.

By LOSE I meant unknowingly lost - not that once I lose it and KNOW I’ve lost 
it I deactivate the keys - and by then the system may be compromised anyway 
(think murder to steal the hardware device - the victim is not reporting the 
device stolen).

Now sometimes that secondary info might be a retina or fingerprint scan, but 
the point is if the machine providing the information has been compromised 
(root access granted), they are free to alter the binaries and the OS itself, 
to compromise these procedures, meaning they probably already captured these 
elements already (prior to the crime).

It is the coupling of the two scenarios - the security cannot be based on the 
hardware device alone (since it can be lost/stolen), and when there is backup 
identifying information, that can be compromised (if the machine is 
compromised).

I know very well how the hardware devices work.


> On Oct 15, 2018, at 7:12 PM, Christopher Nielsen  wrote:
> 
> On Mon, Oct 15, 2018 at 4:33 PM robert engels  wrote:
>> 
>> To clarify, this is for a hardware device that protects a local resource - a 
>> network based protocol that challenges the device for access is a different 
>> story, and yes, when properly implemented is secure (unless someone steals 
>> your device! - which is why it is usually password + device, and then you 
>> are back to the same problem of compromising passwords when root access has 
>> been compromised).
> 
> This statement indicates to me you don't understand how hardware
> security tokens work. It doesn't matter if you have root access. You
> cannot obtain key material from it. If you lose it, you lose the set
> of keys on it. That's it. Revoke them and issue new ones using your
> root cert/key that never touches a networked system and lives in a
> safe.
> 
> -- 
> Christopher Nielsen
> "They who can give up essential liberty for temporary safety, deserve
> neither liberty nor safety." --Benjamin Franklin
> "The tree of liberty must be refreshed from time to time with the
> blood of patriots & tyrants." --Thomas Jefferson
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Understanding the doc (why can't I?)

[Bakul Shah]

On Oct 15, 2018, at 6:44 PM, Neil Higgins <1955ne...@gmail.com> wrote:
> 
> Ok, Dan. With what you have told me, I acknowledge that shuffling is what 
> it’s all about, so the metaphysics matches the physics on this case. So the 
> problem is on my side: Probably a deficit in fluency with idiomatic code. 

May be it ought to be called FYShuffle? The strange prefix is indicates the 
user better read the documentation -- this is not like shuffling cards. Just as 
various hash functions are typically associated with weird names. e.g FNV hash 
(Fowler-Noll-Vo hash), murmur hash and so on. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Understanding the doc (why can't I?)

[Neil Higgins]

Ok, Dan. With what you have told me, I acknowledge that shuffling is what it’s 
all about, so the metaphysics matches the physics on this case. So the problem 
is on my side: Probably a deficit in fluency with idiomatic code. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Understanding the doc (why can't I?)

[Dan Kortschak]

I'm curious. What name would you suggest?

Note that what I said below applies here; shuffling is what is the
intended use of rand.Shuffle. It could conceivably be used for
alternative things, but then C's sprintf can be used for writing to
arbitrary memory, though that is not what is intended. Should sprintf
be renamed to "writememory"?

ApplyFisherYatesIndexPairsToFunc would be the most accurate (beyond
just making the code be the documentation), but that then depends on
the user knowing that Fisher-Yates is a shuffling mechanism in the
common case, and knowing what Fisher-Yates does in the general case.
The current situation leads someone who's looking to shuffle something
to the function, and then provides two examples to show how that works.

There is obviously some assumed common knowledge, but without that
assumption things become untenable.

On Tue, 2018-10-16 at 10:39 +1000, Neil Higgins wrote:
> I would ascribe metaphysicality to the current name, and
> comprehensibility to a more accurate name. In this case, “shuffling”
> is just an example of what can be done. Abstraction is all very nice,
> until any applied meaning is completely lost in mumbo-jumbo.
>
> Neil Higgins (iPhone)
> higgins-dem...@bigpond.com
>
> >
> > On 16 Oct 2018, at 10:20 am, Dan Kortschak  > edu.au> wrote:
> >
> > But this is not really what it does. You can see from the output of
> > this code https://play.golang.org/p/88Llo7zHTeK
> >
> > ```
> > package main
> >
> > import (
> > "fmt"
> > "math/rand"
> > )
> >
> > func main() {
> > rand.Shuffle(10, func(i, j int) {
> > fmt.Println(i, j)
> > })
> > }
> > ```
> >
> > That `i` is not sampled from a random distribution, but in fact
> > counts
> > down from the last index.
> >
> > This is an implementation of the Fisher-Yates shuffle https://golan
> > g.or
> > g/src/math/rand/rand.go?s=7456:7506#L225
> >
> > The reason that rand.Shuffle is called Shuffle is that that is it's
> > intention. Just as sort.Sort has the intention of sorting things,
> > but
> > needn't necessarily (https://play.golang.org/p/VdMuiFfcp6w).
> >
> > If we want to get metaphysical, nothing that we get the machine
> > todo
> > intrinsically means anything beyond what meaning we ascribe to it
> > (under some transformation or set of bases). This is why we name
> > things
> > and why those names matter.
> >
> > >
> > > On Tue, 2018-10-16 at 08:49 +1000, Neil Higgins wrote:
> > > So as well as getting rid of the euphemistic name, the
> > > documentation
> > > should simply say that it delivers n pairs of random numbers in
> > > the
> > > relevant range to a user-defined function.
> > >
> > > Neil Higgins (iPhone)
> > > higgins-dem...@bigpond.com
> > >
> > > >
> > > >
> > > > On 16 Oct 2018, at 8:31 am, Neil Higgins <1955ne...@gmail.com>
> > > > wrote:
> > > >
> > > > Well, ok. But I would call “Shuffle” a misleading misnomer,
> > > > because
> > > > until the user defines a shuffler function (which perversely
> > > > might
> > > > not, or might fail to, shuffle anything), it does not shuffle
> > > > anything.
> > > >
> > > > Thanks for taking the time to answer my question. Neil

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Understanding the doc (why can't I?)

[Neil Higgins]

I would ascribe metaphysicality to the current name, and comprehensibility to a 
more accurate name. In this case, “shuffling” is just an example of what can be 
done. Abstraction is all very nice, until any applied meaning is completely 
lost in mumbo-jumbo.

Neil Higgins (iPhone)
higgins-dem...@bigpond.com

> On 16 Oct 2018, at 10:20 am, Dan Kortschak  
> wrote:
> 
> But this is not really what it does. You can see from the output of
> this code https://play.golang.org/p/88Llo7zHTeK
> 
> ```
> package main
> 
> import (
> "fmt"
> "math/rand"
> )
> 
> func main() {
> rand.Shuffle(10, func(i, j int) {
> fmt.Println(i, j)
> })
> }
> ```
> 
> That `i` is not sampled from a random distribution, but in fact counts
> down from the last index.
> 
> This is an implementation of the Fisher-Yates shuffle https://golang.or
> g/src/math/rand/rand.go?s=7456:7506#L225
> 
> The reason that rand.Shuffle is called Shuffle is that that is it's
> intention. Just as sort.Sort has the intention of sorting things, but
> needn't necessarily (https://play.golang.org/p/VdMuiFfcp6w).
> 
> If we want to get metaphysical, nothing that we get the machine todo
> intrinsically means anything beyond what meaning we ascribe to it
> (under some transformation or set of bases). This is why we name things
> and why those names matter.
> 
>> On Tue, 2018-10-16 at 08:49 +1000, Neil Higgins wrote:
>> So as well as getting rid of the euphemistic name, the documentation
>> should simply say that it delivers n pairs of random numbers in the
>> relevant range to a user-defined function.
>> 
>> Neil Higgins (iPhone)
>> higgins-dem...@bigpond.com
>> 
>>> 
>>> On 16 Oct 2018, at 8:31 am, Neil Higgins <1955ne...@gmail.com>
>>> wrote:
>>> 
>>> Well, ok. But I would call “Shuffle” a misleading misnomer, because
>>> until the user defines a shuffler function (which perversely might
>>> not, or might fail to, shuffle anything), it does not shuffle
>>> anything.
>>> 
>>> Thanks for taking the time to answer my question. Neil

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Understanding the doc (why can't I?)

[Dan Kortschak]

But this is not really what it does. You can see from the output of
this code https://play.golang.org/p/88Llo7zHTeK

```
package main

import (
"fmt"
"math/rand"
)

func main() {
rand.Shuffle(10, func(i, j int) {
fmt.Println(i, j)
})
}
```

That `i` is not sampled from a random distribution, but in fact counts
down from the last index.

This is an implementation of the Fisher-Yates shuffle https://golang.or
g/src/math/rand/rand.go?s=7456:7506#L225

The reason that rand.Shuffle is called Shuffle is that that is it's
intention. Just as sort.Sort has the intention of sorting things, but
needn't necessarily (https://play.golang.org/p/VdMuiFfcp6w).

If we want to get metaphysical, nothing that we get the machine todo
intrinsically means anything beyond what meaning we ascribe to it
(under some transformation or set of bases). This is why we name things
and why those names matter.

On Tue, 2018-10-16 at 08:49 +1000, Neil Higgins wrote:
> So as well as getting rid of the euphemistic name, the documentation
> should simply say that it delivers n pairs of random numbers in the
> relevant range to a user-defined function.
>
> Neil Higgins (iPhone)
> higgins-dem...@bigpond.com
>
> >
> > On 16 Oct 2018, at 8:31 am, Neil Higgins <1955ne...@gmail.com>
> > wrote:
> >
> > Well, ok. But I would call “Shuffle” a misleading misnomer, because
> > until the user defines a shuffler function (which perversely might
> > not, or might fail to, shuffle anything), it does not shuffle
> > anything.
> >
> > Thanks for taking the time to answer my question. Neil

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

[Christopher Nielsen]

On Mon, Oct 15, 2018 at 4:33 PM robert engels  wrote:
>
> To clarify, this is for a hardware device that protects a local resource - a 
> network based protocol that challenges the device for access is a different 
> story, and yes, when properly implemented is secure (unless someone steals 
> your device! - which is why it is usually password + device, and then you are 
> back to the same problem of compromising passwords when root access has been 
> compromised).

This statement indicates to me you don't understand how hardware
security tokens work. It doesn't matter if you have root access. You
cannot obtain key material from it. If you lose it, you lose the set
of keys on it. That's it. Revoke them and issue new ones using your
root cert/key that never touches a networked system and lives in a
safe.

-- 
Christopher Nielsen
"They who can give up essential liberty for temporary safety, deserve
neither liberty nor safety." --Benjamin Franklin
"The tree of liberty must be refreshed from time to time with the
blood of patriots & tyrants." --Thomas Jefferson

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

[Christopher Nielsen]

On Mon, Oct 15, 2018 at 4:25 PM robert engels  wrote:
>
> Maybe, but still, if they have root access to your machine, they can just as 
> easily alter the accessing binary to send the decoded password elsewhere 
> after it has decoded it…

Which is why you disable remote root access on hosts that run security
services...
If someone has physical access, all bets are off anyway.

> Which is why applications on osx are “signed” (to prohibit tampering) 
> (although if you have root access - you could probably also add the bogus 
> singing cert to the certificate store). As far as I know Linux and its 
> variants don’t enforced signed binaries.

I am aware of why macos, iOS, android, etc. sign apps. Thanks.

Adding a bogus signing cert to the app store would be a rather
sophisticated attack, and I am relatively certain having root access
on a client system would not grant that ability. Also, doing that in
an undetectable way would also be a sophisticated attack.

I don't know of a linux distribution that enforces signed binaries,
but packages are signed. Not the same, of course, but close. There is
also apparmor and SElinux to enforce isolation.

> I only point this out because you give the impression that because you “use a 
> hardware device” it is secure - this is not really the case.

I don't think I gave that impression at all. Absolute security that is
in any way functional doesn't exist. Without question, using a
hardware security device is more secure than the alternatives. Saying
"that is not really the case" isn't correct.

> Security is always a trade-off.

Though I didn't state that explicitly, I feel it was implicit in my
comments about threat modeling.

-- 
Christopher Nielsen
"They who can give up essential liberty for temporary safety, deserve
neither liberty nor safety." --Benjamin Franklin
"The tree of liberty must be refreshed from time to time with the
blood of patriots & tyrants." --Thomas Jefferson

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

[robert engels]

To clarify, this is for a hardware device that protects a local resource - a 
network based protocol that challenges the device for access is a different 
story, and yes, when properly implemented is secure (unless someone steals your 
device! - which is why it is usually password + device, and then you are back 
to the same problem of compromising passwords when root access has been 
compromised). 

> On Oct 15, 2018, at 6:25 PM, robert engels  wrote:
> 
> Maybe, but still, if they have root access to your machine, they can just as 
> easily alter the accessing binary to send the decoded password elsewhere 
> after it has decoded it…
> 
> Which is why applications on osx are “signed” (to prohibit tampering) 
> (although if you have root access - you could probably also add the bogus 
> singing cert to the certificate store). As far as I know Linux and its 
> variants don’t enforced signed binaries.
> 
> I only point this out because you give the impression that because you “use a 
> hardware device” it is secure - this is not really the case.
> 
> Security is always a trade-off.
> 
>> On Oct 15, 2018, at 6:04 PM, Christopher Nielsen  wrote:
>> 
>> On Mon, Oct 15, 2018 at 3:10 PM robert engels  wrote:
>>> 
>>> Exactly - and systems do not typically have this - yet are considered 
>>> secure. If the plain text is ever available - and it almost always is (in 
>>> the original input component, etc.) it is always subject to attack/hack - 
>>> and as far as I am aware without hardware support (dongle, etc.) this is a 
>>> limitation of all security implementations.
>> 
>> Considered secure by whom? Maybe "secure enough" by most. At the end
>> of the day, you have to look at your threat model, attack surface,
>> potential attackers, and value of what you want to protect. A password
>> manager is a high-value target for obvious reasons. It should have a
>> well-defined and vetted security model. Personally, I use a hardware
>> security token to secure mine because I don't trust software.
>> 
>>> You don’t always need the plain text though, you can store the one way hash 
>>> (as in Http Digest security), and use that, so if the store is compromised 
>>> the users known passwords are not discovered - but it doesn’t mean access 
>>> won’t be granted.
>> 
>> Sure. It depends what you're doing, of course.
>> 
>>> As far as I know - even ‘keychain access’ in osx (used in millions of 
>>> systems) would be subject to similar hack to if root was available and 
>>> memory could be scanned.
>> 
>> It does not follow that because something is used by millions that it
>> is secure. Again, maybe "secure enough" for most. I also use a
>> hardware token with keychain.
>> 
>> We seem to have wandered pretty far afield of the topic of this forum.
>> 
>> -- 
>> Christopher Nielsen
>> "They who can give up essential liberty for temporary safety, deserve
>> neither liberty nor safety." --Benjamin Franklin
>> "The tree of liberty must be refreshed from time to time with the
>> blood of patriots & tyrants." --Thomas Jefferson
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

[robert engels]

Maybe, but still, if they have root access to your machine, they can just as 
easily alter the accessing binary to send the decoded password elsewhere after 
it has decoded it…

Which is why applications on osx are “signed” (to prohibit tampering) (although 
if you have root access - you could probably also add the bogus singing cert to 
the certificate store). As far as I know Linux and its variants don’t enforced 
signed binaries.

I only point this out because you give the impression that because you “use a 
hardware device” it is secure - this is not really the case.

Security is always a trade-off.

> On Oct 15, 2018, at 6:04 PM, Christopher Nielsen  wrote:
> 
> On Mon, Oct 15, 2018 at 3:10 PM robert engels  wrote:
>> 
>> Exactly - and systems do not typically have this - yet are considered 
>> secure. If the plain text is ever available - and it almost always is (in 
>> the original input component, etc.) it is always subject to attack/hack - 
>> and as far as I am aware without hardware support (dongle, etc.) this is a 
>> limitation of all security implementations.
> 
> Considered secure by whom? Maybe "secure enough" by most. At the end
> of the day, you have to look at your threat model, attack surface,
> potential attackers, and value of what you want to protect. A password
> manager is a high-value target for obvious reasons. It should have a
> well-defined and vetted security model. Personally, I use a hardware
> security token to secure mine because I don't trust software.
> 
>> You don’t always need the plain text though, you can store the one way hash 
>> (as in Http Digest security), and use that, so if the store is compromised 
>> the users known passwords are not discovered - but it doesn’t mean access 
>> won’t be granted.
> 
> Sure. It depends what you're doing, of course.
> 
>> As far as I know - even ‘keychain access’ in osx (used in millions of 
>> systems) would be subject to similar hack to if root was available and 
>> memory could be scanned.
> 
> It does not follow that because something is used by millions that it
> is secure. Again, maybe "secure enough" for most. I also use a
> hardware token with keychain.
> 
> We seem to have wandered pretty far afield of the topic of this forum.
> 
> -- 
> Christopher Nielsen
> "They who can give up essential liberty for temporary safety, deserve
> neither liberty nor safety." --Benjamin Franklin
> "The tree of liberty must be refreshed from time to time with the
> blood of patriots & tyrants." --Thomas Jefferson
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

[Christopher Nielsen]

On Mon, Oct 15, 2018 at 3:10 PM robert engels  wrote:
>
> Exactly - and systems do not typically have this - yet are considered secure. 
> If the plain text is ever available - and it almost always is (in the 
> original input component, etc.) it is always subject to attack/hack - and as 
> far as I am aware without hardware support (dongle, etc.) this is a 
> limitation of all security implementations.

Considered secure by whom? Maybe "secure enough" by most. At the end
of the day, you have to look at your threat model, attack surface,
potential attackers, and value of what you want to protect. A password
manager is a high-value target for obvious reasons. It should have a
well-defined and vetted security model. Personally, I use a hardware
security token to secure mine because I don't trust software.

> You don’t always need the plain text though, you can store the one way hash 
> (as in Http Digest security), and use that, so if the store is compromised 
> the users known passwords are not discovered - but it doesn’t mean access 
> won’t be granted.

Sure. It depends what you're doing, of course.

> As far as I know - even ‘keychain access’ in osx (used in millions of 
> systems) would be subject to similar hack to if root was available and memory 
> could be scanned.

It does not follow that because something is used by millions that it
is secure. Again, maybe "secure enough" for most. I also use a
hardware token with keychain.

We seem to have wandered pretty far afield of the topic of this forum.

-- 
Christopher Nielsen
"They who can give up essential liberty for temporary safety, deserve
neither liberty nor safety." --Benjamin Franklin
"The tree of liberty must be refreshed from time to time with the
blood of patriots & tyrants." --Thomas Jefferson

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Understanding the doc (why can't I?)

[Neil Higgins]

So as well as getting rid of the euphemistic name, the documentation should 
simply say that it delivers n pairs of random numbers in the relevant range to 
a user-defined function. 

Neil Higgins (iPhone)
higgins-dem...@bigpond.com

> On 16 Oct 2018, at 8:31 am, Neil Higgins <1955ne...@gmail.com> wrote:
> 
> Well, ok. But I would call “Shuffle” a misleading misnomer, because until the 
> user defines a shuffler function (which perversely might not, or might fail 
> to, shuffle anything), it does not shuffle anything.
> 
> Thanks for taking the time to answer my question. Neil

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Understanding the doc (why can't I?)

[andrey mirtchovski]

> Well, ok. But I would call “Shuffle” a misleading misnomer, because until the 
> user defines a shuffler function (which perversely might not, or might fail 
> to, shuffle anything), it does not shuffle anything.

how would you implement shuffle in golang so that it's not a
misleading misnomer? i would presume that you would give Shuffle a
slice and expect it to return it shuffled? but then if the slice is
empty, Shuffle has still not shuffled anything :)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Understanding the doc (why can't I?)

[Neil Higgins]

Well, ok. But I would call “Shuffle” a misleading misnomer, because until the 
user defines a shuffler function (which perversely might not, or might fail to, 
shuffle anything), it does not shuffle anything.

Thanks for taking the time to answer my question. Neil

> On 16 Oct 2018, at 2:38 am, Chris Hopkins  wrote:
> 
> I've edited the example very slightly at:
> https://play.golang.org/p/s7CUSbS8P3I
> 
> Let's break this down.
> Think about how you might shuffle a pack of cards, a simple way is to swap 2 
> cards around at a time. As long as you exchange enough cards enough times and 
> both cards you chose are randomly picked, eventually you'll have shuffled the 
> pack. Please be happy with that as a concept before going further.
> 
> The rand.Shuffle therefore doesn't care about what it has to shuffle. All it 
> "thinks" about is: swap element 2 and 7, swap element 24 and 9 etc. (the 
> numbers aren't important here, just that anything in an array can be shuffled 
> by giving these sorts of instructions). All it needs to know is how long the 
> array it has to shuffle is, and "who" can swap things around. I'll repeat 
> that as it might not be obvious. It doesn't have to know how to swap things, 
> it doesn;t have to know anything about the things. If I told you to shuffle 
> 52 cards by shouting out numbers, the exact same instruction if you were 
> instead shuffling 52 cars, or airplanes, or dogs; it's the number of things 
> in the list and the numbers given as instructions that matter. It therefore 
> only has to know of a function that can do this swap around. So we also pass 
> it what I have called swapper. Who is an agent who you say, swap 2 and 7, 24 
> and 9, etc and it will do that.
> So it can call swapper with i and j set to two values and swapper does the 
> swap.
> 
> So how does this play into go:
> Well we've declared the initial array as an array of words.
> We've now declared swapper as someone who can carry out the function of 
> swapping any 2 items in that array, that is the item at location i gets put 
> at the position j was and the item at location j gets put where i was. I 
> explicitly declared swapper as a func that takes two integers as that's the 
> only thing rand.Shuffle knows or cars about the function. It just calls it a 
> whole bunch of times, doesn't pay attention to anything it does, it just 
> trusts it to do what needs to be done.
> So as far as rand.Shuffle goes, it needs how many items are in the array, and 
> a function that it can call with two integer parameters. so we sat to 
> rand.shuffle what the length of the array is, and to use swapper.
> 
> And that's it. Don't worry about how rand.Shuffle works (until you want to). 
> Yes it's a good bit of computer science to understand how it works, but it's 
> also good computer science to accept that you don't need to know how things 
> work under the hood either.
> 
> If that overly wordy version helps?
> 
> Chris
>> On Monday, 15 October 2018 15:06:58 UTC+1, Neil Higgins wrote:
>> Here's the doc for shuffle in math/random:
>> 
>> func Shuffle(n int, swap func(i, j int))
>> Shuffle pseudo-randomizes the order of elements using the default Source. n 
>> is the number of elements. Shuffle panics if n < 0. swap swaps the elements 
>> with indexes i and j.
>> 
>> 
>> And here's the example:
>> 
>> package main
>> 
>> import (
>> "fmt"
>> "math/rand"
>> "strings"
>> )
>> 
>> func main() {
>> words := strings.Fields("ink runs from the corners of my mouth")
>> rand.Shuffle(len(words), func(i, j int) {
>> words[i], words[j] = words[j], words[i]
>> })
>> fmt.Println(words)
>> 
>> }
>> 
>> Why can't I understand a word of it?
>> (This is not atypical, by the way - and not just for go - so if someone can 
>> educate me, I might suddenly start prospering in the software game)
>> 
>> Issues (for me):
>> Shuffle doesn't seem to swap anything (the thing you want shuffled isn't 
>> even an argument)
>> As I read it the example, it should only swap two words (index i and j) but 
>> it seems to shuffle the everything
>> What's this bloody "func" thing???
>> Why doesn't "swap" appear in the example?
>> Yours sincerely,
>> Confused
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "golang-nuts" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/golang-nuts/ICTwCqa8SgE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

[robert engels]

Exactly - and systems do not typically have this - yet are considered secure. 
If the plain text is ever available - and it almost always is (in the original 
input component, etc.) it is always subject to attack/hack - and as far as I am 
aware without hardware support (dongle, etc.) this is a limitation of all 
security implementations.

You don’t always need the plain text though, you can store the one way hash (as 
in Http Digest security), and use that, so if the store is compromised the 
users known passwords are not discovered - but it doesn’t mean access won’t be 
granted.

As far as I know - even ‘keychain access’ in osx (used in millions of systems) 
would be subject to similar hack to if root was available and memory could be 
scanned.

> On Oct 15, 2018, at 4:58 PM, Christopher Nielsen  wrote:
> 
> On Mon, Oct 15, 2018 at 2:17 PM robert engels  > wrote:
>> 
>> As long as the passwords are not stored in plain text in memory - meaning 
>> they are only temporarily decoded in order to be provided (and then the 
>> memory wiped) - there is no difference than the underlying security of the 
>> file encryption on disk, no ?
>> 
>>> On Oct 15, 2018, at 4:13 PM, Christopher Nielsen  
>>> wrote:
>>> 
>>> On Mon, Oct 15, 2018 at 1:28 PM Matthias Schmidt
>>>  wrote:
 
 Hi Eric,
 
 thanks *a lot* for your valuable feedback! I really appreciate it. See 
 comments inline:
 
 Am Montag, 15. Oktober 2018 12:09:32 UTC+2 schrieb EricR:
> 
> Since you're looking for opinions on the security concept, two questions 
> spring immediately to my mind:
> 
> 1. Does the daemon keep the sensitive data in locked memory that cannot 
> be paged out? If so, how cross-platform is this?
 
 
 No it doesn't. As of now i consider the root-user a good guy ;-)
 He's the only one who could access the pagefiles anyway.
 
 So is this really an issue? If yes i could use this cross-platform 
 solution to pin the key:
 
 https://github.com/awnumar/memguard
 
 
> 
> 
> 2. How does the client communicate securely with the daemon? Which 
> encryption protocol/handshake is used for this? (If it just uses a 
> socket, what would prevent another process from reading out the master 
> password?)
 
 
 It's in fact a unix domain socket file which is only accessible for the 
 owner of the key. ( Thanks for bringing this up, i forgot to flag the file 
 correctly - it's now fixed).
 Relying on the file permissions in unix shouldn't be a problem, right?
 
 cheers & again - many thanks,
 
 Matthias
>>> 
>>> You seem to be putting a lot of trust in facilities that are trivially
>>> exploitable to a determined attacker. For software like a password
>>> manager, assuming the kernel is secure is a poor security model. In
>>> addition to the existing attack surface, we live in a world where
>>> side-channel attacks are becoming more common, e.g., Spectre and
>>> Meltdown, so it isn't safe to assume the kernel or hardware are
>>> secure. A password manager needs to have a robust security model that
>>> has a minimal trust model if it is to be more than a toy.
>>> 
>>> Just my $0.02
> 
> Not sure how you expect the password to not be stored in memory in
> plaintext at some point. Without a secure hardware coprocessor with
> secure memory, the system is still susceptible to at least
> side-channel and potentially timing attacks.
> 
> -- 
> Christopher Nielsen
> "They who can give up essential liberty for temporary safety, deserve
> neither liberty nor safety." --Benjamin Franklin
> "The tree of liberty must be refreshed from time to time with the
> blood of patriots & tyrants." --Thomas Jefferson

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

[robert engels]

If the user has the ability to read the page file - i.e. root - then he also 
has the ability to use the debugger to inspect the live memory as well - so as 
the OP pointed out - if root is compromised - nothing is secure.

> On Oct 15, 2018, at 4:36 PM, EricR  wrote:
> 
> If the memory in which the master key resides is not locked, then it may be 
> written to the page file. An attacker may thus boot the machine from an 
> external disk, mount the disk, read the page file, obtain the master key from 
> the page file, and then decrypt the password database. The attack requires 
> physical access but also works with a cloned disk, so the user need not even 
> realize it has happened.
> 
> It's a standard attack. It's also not far-fetched to assume that an attacker 
> could create memory pressure, for example by running a trojan process as an 
> ordinary that uses as much available memory as possible, in order to ensure 
> the master key is paged to disk.
> 
> Whether you want to safeguard against this scenario or not is another 
> question, it always depends on the threat model. I don't know how good this 
> memguard is, but if it does what it promises, then it would likely make the 
> application more secure.
> 
> On Monday, October 15, 2018 at 9:18:18 PM UTC, robert engels wrote:
> As long as the passwords are not stored in plain text in memory - meaning 
> they are only temporarily decoded in order to be provided (and then the 
> memory wiped) - there is no difference than the underlying security of the 
> file encryption on disk, no ? 
> 
> > On Oct 15, 2018, at 4:13 PM, Christopher Nielsen gmail.com 
> > > wrote: 
> > 
> > On Mon, Oct 15, 2018 at 1:28 PM Matthias Schmidt 
> > gmail.com > wrote: 
> >> 
> >> Hi Eric, 
> >> 
> >> thanks *a lot* for your valuable feedback! I really appreciate it. See 
> >> comments inline: 
> >> 
> >> Am Montag, 15. Oktober 2018 12:09:32 UTC+2 schrieb EricR: 
> >>> 
> >>> Since you're looking for opinions on the security concept, two questions 
> >>> spring immediately to my mind: 
> >>> 
> >>> 1. Does the daemon keep the sensitive data in locked memory that cannot 
> >>> be paged out? If so, how cross-platform is this? 
> >> 
> >> 
> >> No it doesn't. As of now i consider the root-user a good guy ;-) 
> >> He's the only one who could access the pagefiles anyway. 
> >> 
> >> So is this really an issue? If yes i could use this cross-platform 
> >> solution to pin the key: 
> >> 
> >> https://github.com/awnumar/memguard  
> >> 
> >> 
> >>> 
> >>> 
> >>> 2. How does the client communicate securely with the daemon? Which 
> >>> encryption protocol/handshake is used for this? (If it just uses a 
> >>> socket, what would prevent another process from reading out the master 
> >>> password?) 
> >> 
> >> 
> >> It's in fact a unix domain socket file which is only accessible for the 
> >> owner of the key. ( Thanks for bringing this up, i forgot to flag the file 
> >> correctly - it's now fixed). 
> >> Relying on the file permissions in unix shouldn't be a problem, right? 
> >> 
> >> cheers & again - many thanks, 
> >> 
> >> Matthias 
> > 
> > You seem to be putting a lot of trust in facilities that are trivially 
> > exploitable to a determined attacker. For software like a password 
> > manager, assuming the kernel is secure is a poor security model. In 
> > addition to the existing attack surface, we live in a world where 
> > side-channel attacks are becoming more common, e.g., Spectre and 
> > Meltdown, so it isn't safe to assume the kernel or hardware are 
> > secure. A password manager needs to have a robust security model that 
> > has a minimal trust model if it is to be more than a toy. 
> > 
> > Just my $0.02 
> > 
> > -- 
> > Christopher Nielsen 
> > "They who can give up essential liberty for temporary safety, deserve 
> > neither liberty nor safety." --Benjamin Franklin 
> > "The tree of liberty must be refreshed from time to time with the 
> > blood of patriots & tyrants." --Thomas Jefferson 
> > 
> > -- 
> > You received this message because you are subscribed to the Google Groups 
> > "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to golang-nuts...@ <>googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout 
> > . 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop 

Re: [go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

[Christopher Nielsen]

On Mon, Oct 15, 2018 at 2:17 PM robert engels  wrote:
>
> As long as the passwords are not stored in plain text in memory - meaning 
> they are only temporarily decoded in order to be provided (and then the 
> memory wiped) - there is no difference than the underlying security of the 
> file encryption on disk, no ?
>
> > On Oct 15, 2018, at 4:13 PM, Christopher Nielsen  
> > wrote:
> >
> > On Mon, Oct 15, 2018 at 1:28 PM Matthias Schmidt
> >  wrote:
> >>
> >> Hi Eric,
> >>
> >> thanks *a lot* for your valuable feedback! I really appreciate it. See 
> >> comments inline:
> >>
> >> Am Montag, 15. Oktober 2018 12:09:32 UTC+2 schrieb EricR:
> >>>
> >>> Since you're looking for opinions on the security concept, two questions 
> >>> spring immediately to my mind:
> >>>
> >>> 1. Does the daemon keep the sensitive data in locked memory that cannot 
> >>> be paged out? If so, how cross-platform is this?
> >>
> >>
> >> No it doesn't. As of now i consider the root-user a good guy ;-)
> >> He's the only one who could access the pagefiles anyway.
> >>
> >> So is this really an issue? If yes i could use this cross-platform 
> >> solution to pin the key:
> >>
> >> https://github.com/awnumar/memguard
> >>
> >>
> >>>
> >>>
> >>> 2. How does the client communicate securely with the daemon? Which 
> >>> encryption protocol/handshake is used for this? (If it just uses a 
> >>> socket, what would prevent another process from reading out the master 
> >>> password?)
> >>
> >>
> >> It's in fact a unix domain socket file which is only accessible for the 
> >> owner of the key. ( Thanks for bringing this up, i forgot to flag the file 
> >> correctly - it's now fixed).
> >> Relying on the file permissions in unix shouldn't be a problem, right?
> >>
> >> cheers & again - many thanks,
> >>
> >> Matthias
> >
> > You seem to be putting a lot of trust in facilities that are trivially
> > exploitable to a determined attacker. For software like a password
> > manager, assuming the kernel is secure is a poor security model. In
> > addition to the existing attack surface, we live in a world where
> > side-channel attacks are becoming more common, e.g., Spectre and
> > Meltdown, so it isn't safe to assume the kernel or hardware are
> > secure. A password manager needs to have a robust security model that
> > has a minimal trust model if it is to be more than a toy.
> >
> > Just my $0.02

Not sure how you expect the password to not be stored in memory in
plaintext at some point. Without a secure hardware coprocessor with
secure memory, the system is still susceptible to at least
side-channel and potentially timing attacks.

-- 
Christopher Nielsen
"They who can give up essential liberty for temporary safety, deserve
neither liberty nor safety." --Benjamin Franklin
"The tree of liberty must be refreshed from time to time with the
blood of patriots & tyrants." --Thomas Jefferson

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

[EricR]

If the memory in which the master key resides is not locked, then it may be 
written to the page file. An attacker may thus boot the machine from an 
external disk, mount the disk, read the page file, obtain the master key 
from the page file, and then decrypt the password database. The attack 
requires physical access but also works with a cloned disk, so the user 
need not even realize it has happened.

It's a standard attack. It's also not far-fetched to assume that an 
attacker could create memory pressure, for example by running a trojan 
process as an ordinary that uses as much available memory as possible, in 
order to ensure the master key is paged to disk.

Whether you want to safeguard against this scenario or not is another 
question, it always depends on the threat model. I don't know how good this 
memguard is, but if it does what it promises, then it would likely make the 
application more secure.

On Monday, October 15, 2018 at 9:18:18 PM UTC, robert engels wrote:
>
> As long as the passwords are not stored in plain text in memory - meaning 
> they are only temporarily decoded in order to be provided (and then the 
> memory wiped) - there is no difference than the underlying security of the 
> file encryption on disk, no ? 
>
> > On Oct 15, 2018, at 4:13 PM, Christopher Nielsen  > wrote: 
> > 
> > On Mon, Oct 15, 2018 at 1:28 PM Matthias Schmidt 
> > > wrote: 
> >> 
> >> Hi Eric, 
> >> 
> >> thanks *a lot* for your valuable feedback! I really appreciate it. See 
> comments inline: 
> >> 
> >> Am Montag, 15. Oktober 2018 12:09:32 UTC+2 schrieb EricR: 
> >>> 
> >>> Since you're looking for opinions on the security concept, two 
> questions spring immediately to my mind: 
> >>> 
> >>> 1. Does the daemon keep the sensitive data in locked memory that 
> cannot be paged out? If so, how cross-platform is this? 
> >> 
> >> 
> >> No it doesn't. As of now i consider the root-user a good guy ;-) 
> >> He's the only one who could access the pagefiles anyway. 
> >> 
> >> So is this really an issue? If yes i could use this cross-platform 
> solution to pin the key: 
> >> 
> >> https://github.com/awnumar/memguard 
> >> 
> >> 
> >>> 
> >>> 
> >>> 2. How does the client communicate securely with the daemon? Which 
> encryption protocol/handshake is used for this? (If it just uses a socket, 
> what would prevent another process from reading out the master password?) 
> >> 
> >> 
> >> It's in fact a unix domain socket file which is only accessible for the 
> owner of the key. ( Thanks for bringing this up, i forgot to flag the file 
> correctly - it's now fixed). 
> >> Relying on the file permissions in unix shouldn't be a problem, right? 
> >> 
> >> cheers & again - many thanks, 
> >> 
> >> Matthias 
> > 
> > You seem to be putting a lot of trust in facilities that are trivially 
> > exploitable to a determined attacker. For software like a password 
> > manager, assuming the kernel is secure is a poor security model. In 
> > addition to the existing attack surface, we live in a world where 
> > side-channel attacks are becoming more common, e.g., Spectre and 
> > Meltdown, so it isn't safe to assume the kernel or hardware are 
> > secure. A password manager needs to have a robust security model that 
> > has a minimal trust model if it is to be more than a toy. 
> > 
> > Just my $0.02 
> > 
> > -- 
> > Christopher Nielsen 
> > "They who can give up essential liberty for temporary safety, deserve 
> > neither liberty nor safety." --Benjamin Franklin 
> > "The tree of liberty must be refreshed from time to time with the 
> > blood of patriots & tyrants." --Thomas Jefferson 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to golang-nuts...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

[robert engels]

As long as the passwords are not stored in plain text in memory - meaning they 
are only temporarily decoded in order to be provided (and then the memory 
wiped) - there is no difference than the underlying security of the file 
encryption on disk, no ?

> On Oct 15, 2018, at 4:13 PM, Christopher Nielsen  wrote:
> 
> On Mon, Oct 15, 2018 at 1:28 PM Matthias Schmidt
>  wrote:
>> 
>> Hi Eric,
>> 
>> thanks *a lot* for your valuable feedback! I really appreciate it. See 
>> comments inline:
>> 
>> Am Montag, 15. Oktober 2018 12:09:32 UTC+2 schrieb EricR:
>>> 
>>> Since you're looking for opinions on the security concept, two questions 
>>> spring immediately to my mind:
>>> 
>>> 1. Does the daemon keep the sensitive data in locked memory that cannot be 
>>> paged out? If so, how cross-platform is this?
>> 
>> 
>> No it doesn't. As of now i consider the root-user a good guy ;-)
>> He's the only one who could access the pagefiles anyway.
>> 
>> So is this really an issue? If yes i could use this cross-platform solution 
>> to pin the key:
>> 
>> https://github.com/awnumar/memguard
>> 
>> 
>>> 
>>> 
>>> 2. How does the client communicate securely with the daemon? Which 
>>> encryption protocol/handshake is used for this? (If it just uses a socket, 
>>> what would prevent another process from reading out the master password?)
>> 
>> 
>> It's in fact a unix domain socket file which is only accessible for the 
>> owner of the key. ( Thanks for bringing this up, i forgot to flag the file 
>> correctly - it's now fixed).
>> Relying on the file permissions in unix shouldn't be a problem, right?
>> 
>> cheers & again - many thanks,
>> 
>> Matthias
> 
> You seem to be putting a lot of trust in facilities that are trivially
> exploitable to a determined attacker. For software like a password
> manager, assuming the kernel is secure is a poor security model. In
> addition to the existing attack surface, we live in a world where
> side-channel attacks are becoming more common, e.g., Spectre and
> Meltdown, so it isn't safe to assume the kernel or hardware are
> secure. A password manager needs to have a robust security model that
> has a minimal trust model if it is to be more than a toy.
> 
> Just my $0.02
> 
> -- 
> Christopher Nielsen
> "They who can give up essential liberty for temporary safety, deserve
> neither liberty nor safety." --Benjamin Franklin
> "The tree of liberty must be refreshed from time to time with the
> blood of patriots & tyrants." --Thomas Jefferson
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

[Christopher Nielsen]

On Mon, Oct 15, 2018 at 1:28 PM Matthias Schmidt
 wrote:
>
> Hi Eric,
>
> thanks *a lot* for your valuable feedback! I really appreciate it. See 
> comments inline:
>
> Am Montag, 15. Oktober 2018 12:09:32 UTC+2 schrieb EricR:
>>
>> Since you're looking for opinions on the security concept, two questions 
>> spring immediately to my mind:
>>
>> 1. Does the daemon keep the sensitive data in locked memory that cannot be 
>> paged out? If so, how cross-platform is this?
>
>
> No it doesn't. As of now i consider the root-user a good guy ;-)
> He's the only one who could access the pagefiles anyway.
>
> So is this really an issue? If yes i could use this cross-platform solution 
> to pin the key:
>
> https://github.com/awnumar/memguard
>
>
>>
>>
>> 2. How does the client communicate securely with the daemon? Which 
>> encryption protocol/handshake is used for this? (If it just uses a socket, 
>> what would prevent another process from reading out the master password?)
>
>
> It's in fact a unix domain socket file which is only accessible for the owner 
> of the key. ( Thanks for bringing this up, i forgot to flag the file 
> correctly - it's now fixed).
> Relying on the file permissions in unix shouldn't be a problem, right?
>
> cheers & again - many thanks,
>
> Matthias

You seem to be putting a lot of trust in facilities that are trivially
exploitable to a determined attacker. For software like a password
manager, assuming the kernel is secure is a poor security model. In
addition to the existing attack surface, we live in a world where
side-channel attacks are becoming more common, e.g., Spectre and
Meltdown, so it isn't safe to assume the kernel or hardware are
secure. A password manager needs to have a robust security model that
has a minimal trust model if it is to be more than a toy.

Just my $0.02

-- 
Christopher Nielsen
"They who can give up essential liberty for temporary safety, deserve
neither liberty nor safety." --Benjamin Franklin
"The tree of liberty must be refreshed from time to time with the
blood of patriots & tyrants." --Thomas Jefferson

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

[Matthias Schmidt]

Hi Eric,

thanks *a lot* for your valuable feedback! I really appreciate it. See 
comments inline:

Am Montag, 15. Oktober 2018 12:09:32 UTC+2 schrieb EricR:
>
> Since you're looking for opinions on the security concept, two questions 
> spring immediately to my mind:
>
> 1. Does the daemon keep the sensitive data in locked memory that cannot be 
> paged out? If so, how cross-platform is this?
>

No it doesn't. As of now i consider the root-user a good guy ;-) 
He's the only one who could access the pagefiles anyway.

So is this really an issue? If yes i could use this cross-platform solution 
to pin the key:

https://github.com/awnumar/memguard

 

>
> 2. How does the client communicate securely with the daemon? Which 
> encryption protocol/handshake is used for this? (If it just uses a socket, 
> what would prevent another process from reading out the master password?)
>

It's in fact a unix domain socket file which is only accessible for the 
owner of the key. ( Thanks for bringing this up, i forgot to flag the file 
correctly - it's now fixed).
Relying on the file permissions in unix shouldn't be a problem, right?

cheers & again - many thanks,

Matthias

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [Proposal] Goroutine Scoped Context

[Eyal]

Part 2: scoped context proposal.

https://posener.github.io/context-scoping/

Please post replies in the blog itself.
Enjoy!

On Wednesday, October 10, 2018 at 9:38:18 PM UTC+3, Eyal wrote:
>
> Hi,
> I wrote a proposal about making the context goroutine scoped.
> Please read the current design problems and how I suggest to solve them:
>
> https://posener.github.io/goroutine-scoped-context
>
> 
> Thanks,
> Eyal
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [ANN] Golem: A general purpose, interpreted scripting language

[Thorsten Sommer]

Thank you Mike, for your announcement. Weird: I was looking for a library 
like this. I will take a closer look at Golem and try to use your language. 
Thank you for your work and the effort you put into Golem.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Understanding the doc (why can't I?)

[Chris Hopkins]

I've edited the example very slightly at:
https://play.golang.org/p/s7CUSbS8P3I

Let's break this down.
Think about how you might shuffle a pack of cards, a simple way is to swap 
2 cards around at a time. As long as you exchange enough cards enough times 
and both cards you chose are randomly picked, eventually you'll have 
shuffled the pack. Please be happy with that as a concept before going 
further.

The rand.Shuffle therefore doesn't care about what it has to shuffle. All 
it "thinks" about is: swap element 2 and 7, swap element 24 and 9 etc. (the 
numbers aren't important here, just that anything in an array can be 
shuffled by giving these sorts of instructions). All it needs to know is 
how long the array it has to shuffle is, and "who" can swap things around. 
I'll repeat that as it might not be obvious. It doesn't have to know how to 
swap things, it doesn;t have to know anything about the things. If I told 
you to shuffle 52 cards by shouting out numbers, the exact same instruction 
if you were instead shuffling 52 cars, or airplanes, or dogs; it's the 
number of things in the list and the numbers given as instructions that 
matter. It therefore only has to know of a function that can do this swap 
around. So we also pass it what I have called swapper. Who is an agent who 
you say, swap 2 and 7, 24 and 9, etc and it will do that.
So it can call swapper with i and j set to two values and swapper does the 
swap.

So how does this play into go:
Well we've declared the initial array as an array of words.
We've now declared swapper as someone who can carry out the function of 
swapping any 2 items in that array, that is the item at location i gets put 
at the position j was and the item at location j gets put where i was. I 
explicitly declared swapper as a func that takes two integers as that's the 
only thing rand.Shuffle knows or cars about the function. It just calls it 
a whole bunch of times, doesn't pay attention to anything it does, it just 
trusts it to do what needs to be done.
So as far as rand.Shuffle goes, it needs how many items are in the array, 
and a function that it can call with two integer parameters. so we sat to 
rand.shuffle what the length of the array is, and to use swapper.

And that's it. Don't worry about how rand.Shuffle works (until you want 
to). Yes it's a good bit of computer science to understand how it works, 
but it's also good computer science to accept that you don't need to know 
how things work under the hood either.

If that overly wordy version helps?

Chris
On Monday, 15 October 2018 15:06:58 UTC+1, Neil Higgins wrote:
>
> *Here's the doc for shuffle in math/random*:
>
> func Shuffle(n int , swap func(i, j int 
> ))
>
> Shuffle pseudo-randomizes the order of elements using the default Source. 
> n is the number of elements. Shuffle panics if n < 0. swap swaps the 
> elements with indexes i and j. 
>
> *And here's the example*:
>
> package main
>
> import (
> "fmt"
> "math/rand"
> "strings"
> )
>
> func main() {
> words := strings.Fields("ink runs from the corners of my mouth")
> rand.Shuffle(len(words), func(i, j int) {
> words[i], words[j] = words[j], words[i]
> })
> fmt.Println(words)
>
> }
>
> *Why can't I understand a word of it?*
> (This is not atypical, by the way - and not just for go - so if someone 
> can educate me, I might suddenly start prospering in the software game)
>
> Issues (for me):
>
>- Shuffle doesn't seem to swap anything (the thing you want shuffled 
>isn't even an argument)
>- As I read it the example, it should only swap two words (index i and 
>j) but it seems to shuffle the everything
>- What's this bloody "func" thing???
>- Why doesn't "swap" appear in the example?
>
> Yours sincerely,
> *Confused*
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Understanding the doc (why can't I?)

[Jan Mercl]

On Mon, Oct 15, 2018 at 4:06 PM <1955ne...@gmail.com> wrote:

> Issues (for me):
>
> Shuffle doesn't seem to swap anything (the thing you want shuffled isn't
even an argument)

It shuffle things by calling the function literal passed to rand.Shufle.
Above it is `func(i, j int) { words[i], words[j] = words[j], words[i] }`.
the `words` slice is not an argument, it's passed as part of a closure of
the anonymous function.

> As I read it the example, it should only swap two words (index i and j)
but it seems to shuffle the everything

It swaps only two words. But Shuffle calls the swap function several times
with different indices.

> What's this bloody "func" thing???

It's a keyword that introduces a definition of a function type or a named
or anonymous function.

> Why doesn't "swap" appear in the example?

It does. 'swap' is the declared name of the function to pass to
rand.Shuffle. The actual argument might be, for example, `foo`, `bar` or a
function literal (anonymous function) as seen above.

Also, see the source of rand.Shuffle here:
https://golang.org/src/math/rand/rand.go?s=7456:7506#L225

-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Understanding the doc (why can't I?)

[1955neilh]

*Here's the doc for shuffle in math/random*:

func Shuffle(n int , swap func(i, j int 
))

Shuffle pseudo-randomizes the order of elements using the default Source. n 
is the number of elements. Shuffle panics if n < 0. swap swaps the elements 
with indexes i and j. 

*And here's the example*:

package main

import (
"fmt"
"math/rand"
"strings"
)

func main() {
words := strings.Fields("ink runs from the corners of my mouth")
rand.Shuffle(len(words), func(i, j int) {
words[i], words[j] = words[j], words[i]
})
fmt.Println(words)

}

*Why can't I understand a word of it?*
(This is not atypical, by the way - and not just for go - so if someone can 
educate me, I might suddenly start prospering in the software game)

Issues (for me):

   - Shuffle doesn't seem to swap anything (the thing you want shuffled 
   isn't even an argument)
   - As I read it the example, it should only swap two words (index i and 
   j) but it seems to shuffle the everything
   - What's this bloody "func" thing???
   - Why doesn't "swap" appear in the example?

Yours sincerely,
*Confused*

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

[EricR]

Since you're looking for opinions on the security concept, two questions 
spring immediately to my mind:

1. Does the daemon keep the sensitive data in locked memory that cannot be 
paged out? If so, how cross-platform is this?

2. How does the client communicate securely with the daemon? Which 
encryption protocol/handshake is used for this? (If it just uses a socket, 
what would prevent another process from reading out the master password?)

Regards,

Eric

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.