Re: [go-nuts] Why can runtime.procyield declare its argument stack size to be zero?

[Jeffrey Baker]

Thanks. Now I feel a bit less crazy.

-jwb

On Tue, Oct 16, 2018 at 5:14 PM Ian Lance Taylor  wrote:

> On Thu, Oct 11, 2018 at 3:01 PM, Jeffrey Baker  wrote:
> >
> > I'm trying to learn how to safely use this asm, and I don't understand
> some
> > of the existing asm in the runtime package.  From amd64.s:
> >
> > TEXT runtime·procyield(SB),NOSPLIT,$0-0
> > MOVL cycles+0(FP), AX
> >
> > My understanding of $0-0 is it's supposed to indicate the sizes of the
> > arguments, in this case would seem to be $0-4 since the argument is
> uint32.
> > Indeed, specializations of this function on other platforms use $0-4,
> such
> > as ppc64:
> >
> > TEXT runtime·procyield(SB),NOSPLIT|NOFRAME,$0-4
> > MOVW cycles+0(FP), R7
> >
> > Why does the amd64 version work? Why doesn't `go vet` complain about it?
>
> I think it's a bug.  Two bugs. Maybe three.  Thanks for pointing it out.
>
> Sent https://golang.org/cl/142758 to start fixing this.
>
> 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] Re: Generics: an unwelcome conclusion and a proposal

[robert engels]

The easiest solution is that []int IS A IntList by definition, no ? Meaning 
that an “slice” has defined methods Len(), and At(). I would personally define 
other methods on slice too for convenience (like, Insert, Delete). The [] 
notation is just syntactic sugar for slice.At(). When used as a left side, it 
is syntactic sugar for Set().

> On Oct 16, 2018, at 6:21 PM, Patrick Smith  wrote:
> 
> On Tue, Oct 16, 2018 at 3:33 AM alanfo  > wrote:
> I would also disallow overloading of the =, :=, <-, ..., [], {}, () and yes - 
> equality operators - as well because I believe to do otherwise would be very 
> confusing. 
> 
> If overloading [] were disallowed, how would one write a generic function 
> taking a single argument of type either []int or a user-defined type with 
> similar behavior, and returning the sum of the elements? Sort of the marriage 
> of these two functions:
> 
> func SumIntSlice(s []int) int {
> sum := 0
> for _, i := range s {
> sum += i
> }
> return sum
> }
> 
> type IntList interface {
> Len() int
> At(int) int
> }
> 
> func SumIntList(l IntList) int {
> sum := 0
> for n := 0; n < l.Len(); n++ {
> sum += l.At(n)
> }
> return sum
> }
> 
> -- 
> 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] Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

[robert engels]

I did some reading on the yubikey, and it works pretty much how I expected, and 
I’m pretty sure my assessment still holds. (And as an aside, up until the 
latest release they were all completely broken… 
https://arstechnica.com/information-technology/2017/10/crypto-failure-cripples-millions-of-high-security-keys-750k-estonian-ids/
 
)

If the authentication is device only, then stealing the device gets you in (I 
can’t imagine any one doing it this way though - I am assuming all services 
probably use two factor for the initial host device login - so you would need 
to still the key and the computer/phone - and if they have that, you are 
probably dead anyway, so you really don’t care at this point).

If it is part of a two factor authentication (password or pin), then if root is 
compromised it doesn’t help anyway, as someone has already installed a key 
tracker, etc. to grab the pin password if needed. The key coupled with external 
 factors (voice, etc.) and machine identity makes it pretty darn safe though… 
(except bugs in the crypto code as above).

At least according to their website on FIDO2:

Now, Yubico has worked in collaboration with Microsoft on the evolution of the 
FIDO U2F authentication standard, to create FIDO2. With FIDO2, the Security Key 
with its strong authentication can now solve multiple use case scenarios and 
experiences:
— second factor in a two factor authentication solution
— strong first factor, with the possession of the device only, allowing for a 
passwordless experience like tap and go
— multi-factor with possession of the device AND PIN, to solve high assurance 
requirements such as financial transactions, or submitting a prescription.
Anyway, your original point about not swapping the master password to disk is 
valid, but if root is comprised I still say it makes no difference as a 
malicious program can watch the application live to steal the password directly 
from pinned, non-swappable memory if so inclined.

I’d probably still buy a yubikey, but it seems to be a nightmare calling 
hundreds of services to tell them my device was lost/stolen. I didn’t see any 
“one point of contact” in this case ??? Can I log into a single yubikey website 
and disable it for all services - doesn’t seem available ?

> On Oct 16, 2018, at 2:37 PM, Christopher Nielsen  wrote:
> 
> Maybe we're talking about different things. Are you thinking of TOTP
> 2FA tokens? Your arguments do apply to those.
> 
> I'm not talking about those. I'm talking about devices like a yubikey,
> which is essentially a  a poor person's HSM.
> On Mon, Oct 15, 2018 at 7:21 PM robert engels  wrote:
>> 
>> 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
>>> 

Re: [go-nuts] Why can runtime.procyield declare its argument stack size to be zero?

[Ian Lance Taylor]

On Thu, Oct 11, 2018 at 3:01 PM, Jeffrey Baker  wrote:
>
> I'm trying to learn how to safely use this asm, and I don't understand some
> of the existing asm in the runtime package.  From amd64.s:
>
> TEXT runtime·procyield(SB),NOSPLIT,$0-0
> MOVL cycles+0(FP), AX
>
> My understanding of $0-0 is it's supposed to indicate the sizes of the
> arguments, in this case would seem to be $0-4 since the argument is uint32.
> Indeed, specializations of this function on other platforms use $0-4, such
> as ppc64:
>
> TEXT runtime·procyield(SB),NOSPLIT|NOFRAME,$0-4
> MOVW cycles+0(FP), R7
>
> Why does the amd64 version work? Why doesn't `go vet` complain about it?

I think it's a bug.  Two bugs. Maybe three.  Thanks for pointing it out.

Sent https://golang.org/cl/142758 to start fixing this.

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] Re: Generics: an unwelcome conclusion and a proposal

[Patrick Smith]

On Tue, Oct 16, 2018 at 3:33 AM alanfo  wrote:

> I would also disallow overloading of the =, :=, <-, ..., [], {}, () and
> yes - equality operators - as well because I believe to do otherwise would
> be very confusing.
>

If overloading [] were disallowed, how would one write a generic function
taking a single argument of type either []int or a user-defined type with
similar behavior, and returning the sum of the elements? Sort of the
marriage of these two functions:

func SumIntSlice(s []int) int {

sum := 0

for _, i := range s {

sum += i

}
return sum

}

type IntList interface {

Len() int

At(int) int

}

func SumIntList(l IntList) int {

sum := 0

for n := 0; n < l.Len(); n++ {

sum += l.At(n)

}

return sum

}

-- 
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 with adaptors

[Ian Denhardt]

Quoting Patrick Smith (2018-10-16 18:32:48)

>The union function could verify that the two adaptors are the same,
>using the == operator, and panic if not. However, this breaks down if
>the adaptors, instead of being defined as struct{}, are defined as
>types which don't support ==.

This works, provided you use the interface approach in most of your
examples. It would be ideal to catch the error at compile time though.

>This could even be construed as a feature. The union function takes two
>sets, possibly with different adaptors, and merges their contents into
>a new set using an adaptor passed as a parameter to union, and which
>could be different from the adaptors for both input sets.

True, although for some cases you really do want to require both
arguments to have the same adaptor. In a persistent set or map based on
persistent trees[1], you can get asymptotic speedups on merge/union
if you can assume the adaptor is the same.

[1]: https://en.wikipedia.org/wiki/Persistent_data_structure#Trees

-- 
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 with adaptors

[Patrick Smith]

On Tue, Oct 16, 2018 at 3:21 PM Ian Denhardt  wrote:

> Quoting Patrick Smith (2018-10-16 18:04:05)
> >One way to avoid this is to supply the adaptor when the Set is
> created,
> >store it in the Set, and thereafter used the stored adaptor instead of
> >requiring an adaptor parameter.
>
> This works for insert/member, but what about union, which takes two
> sets? You could still run into problems if the sets were initialized
> with different adaptors.
>

True. Although:

The union function could verify that the two adaptors are the same, using
the == operator, and panic if not. However, this breaks down if the
adaptors, instead of being defined as struct{}, are defined as types which
don't support ==.

This could even be construed as a feature. The union function takes two
sets, possibly with different adaptors, and merges their contents into a
new set using an adaptor passed as a parameter to union, and which could be
different from the adaptors for both input sets.

-- 
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 with adaptors

[Ian Denhardt]

Quoting Patrick Smith (2018-10-16 18:04:05)

>One way to avoid this is to supply the adaptor when the Set is created,
>store it in the Set, and thereafter used the stored adaptor instead of
>requiring an adaptor parameter.

This works for insert/member, but what about union, which takes two
sets? You could still run into problems if the sets were initialized
with different adaptors.

-- 
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 with adaptors

[Patrick Smith]

On Tue, Oct 16, 2018 at 12:01 PM Ian Denhardt  wrote:

> * We don't actually need an adaptor for the zero value, since we can
>   just declare a variable of the generic type:
>
> func MyFn(type T) {
> // x is the zero value, per usual initialization rules:
> var x T
>

True. This assumes that Go's usual initialization rules for type T produce
a value that will be interpreted as the additive identity for type T.
That's an assumption I would be happy to make.

But there are other values that could be useful and for which this
assumption doesn't hold. For example,

   - One() (the multiplicative identity)
   - MaxValue and MinValue() (extreme values for the type)



> One problem with this design, which bounding solves: Suppose we have a
> generic set type implemented using binary trees (I will use
> the 't notation discussed above, but you could use explicit parameter
> lists as well).
>
> type Order('t) interface{
> Less(x, y 't)
> }
>
> type Set('t) struct {
> // ...
> }
>
> func (s Set('t)) Insert('t; Order('t))
> func (s Set('t)) Member('t; Order('t)) bool
> // etc.
>
> What happens if we accidentally pass different adapters to different
> calls to the methods? e.g:
>

One way to avoid this is to supply the adaptor when the Set is created,
store it in the Set, and thereafter used the stored adaptor instead of
requiring an adaptor parameter.

type Set('t) struct {

o Order('t)
// ...

}


func MakeSet('t)(; o Order('t)) { var s Set('t); /* ... */; s.o = o; return
s }

func (s Set('t)) Insert('t)

func (s Set('t)) Member('t) bool

This presents a bit of a trade-off. Is it better to accept the overhead of
storing the adaptor, or to take the risk of having different adaptors
passed as parameters? The answer will depend on the situation.

-- 
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-16 17:28:11)

>Fair enough. But is there any way to have a contract system of *any*
>kind that doesn't have the identical problem?�

Linked elsewhere in this thread, but I sketched something that I think
does the trick:

https://gist.github.com/zenhack/ad508d08c72fce6df945a49945ad826d

As written it punts on operator overloading, but I think given the
solution you've described re: ==, it can be updated to support 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] Generics: an unwelcome conclusion and a proposal

[Ian Lance Taylor]

On Tue, Oct 16, 2018 at 2:28 PM, Eric Raymond  wrote:
>
> On Tuesday, October 16, 2018 at 4:52:54 PM UTC-4, Ian Denhardt wrote:
>>
>> The trouble is that (in the case where you compile using the implements
>> <, rather than throwing an error) the type signature no longer tells you
>> what the constraints actually are; this information is only in the body
>> of the function, so it's easy to accidentally change it when changing
>> something that you think is just implementation detail.
>
>
> Fair enough. But is there any way to have a contract system of *any* kind
> that doesn't have the identical problem?

The contract system in the generics design draft does not have this
problem.  It may have other problems, but it doesn't have this one.
The contract specifies exactly what the body of the function is
permitted to do, and it specifies a set of requirements on the type
arguments at the call site.  Changing the body of the function can not
affect the call sites.  Only changing the contract itself can do that.

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] Re: Generics with adaptors

[Patrick Smith]

On Tue, Oct 16, 2018 at 5:44 AM Eric Raymond  wrote:

> On Tuesday, October 16, 2018 at 6:34:10 AM UTC-4, Patrick Smith wrote:
>>
>> Yet another generics discussion at
>> https://gist.github.com/pat42smith/ccf021193971f6de6fdb229d68215302
>>
>
> I think it fails Ian Lance Taylor's smoke test.
>

I think this shows that it passes the smoke test:

type Order(type T) interface {

Less(T, T) bool

}

func Min(type T)(a, b T, o Order(T)) {

if o.Less(a, b) {

return a

}

return b

}


Yes, there's an extra parameter o, but that's verbosity, not a failure of
the smoke test.


> I also dislike the verbosity.
>

As do I. Again, this isn't so much a recommendation as a "what if?"
scenario.

-- 
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 Tuesday, October 16, 2018 at 4:52:54 PM UTC-4, Ian Denhardt wrote:
>
> The trouble is that (in the case where you compile using the implements 
> <, rather than throwing an error) the type signature no longer tells you 
> what the constraints actually are; this information is only in the body 
> of the function, so it's easy to accidentally change it when changing 
> something that you think is just implementation detail. 
>

Fair enough. But is there any way to have a contract system of *any* kind 
that doesn't have the identical problem? 

-- 
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 with adaptors

[alanfo]

An interesting and (for me at least) novel approach to contract-free 
generics.

Despite the suggestions towards the end, it's still too verbose for my 
taste but I did find it reassuring that, even without operator overloading 
(Eric's proposal), there would still be a plausible way to write generic 
functions which unified built-in and user defined types.

Alan

On Tuesday, October 16, 2018 at 11:34:10 AM UTC+1, Patrick Smith wrote:
>
> Yet another generics discussion at 
> https://gist.github.com/pat42smith/ccf021193971f6de6fdb229d68215302
>
> This one looks at what programmers would be able to do if very basic 
> generics were added to Go, without contracts. Generic functions may not use 
> methods or operators of their type parameters.
>
> The answer is quite a lot, actually. The code would be verbose, but not 
> impossibly so.
>

-- 
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 Tuesday, October 16, 2018 at 4:41:53 PM UTC-4, Dave MacFarlane wrote:
>
> Now I'm confused about what problem regarding generics you're trying 
> to solve with operator overloading. If you can't assume anything about 
> the meaning of an operator other than "it returns a bool", how could a 
> programmer use them in a generic contract? Or were you suggesting 
> operator overloading *instead of* contracts that exist in the current 
> proposal? (Even in that case, how would a programmer use them in a 
> generic function without their meaning being well defined?) 
>

Reviewing this thread, I find your confusion quite reasonable.  So let me 
lay out my philosophical assumptions more carefully.

An "implements <" clause would have two different kinds of meaning.  One is 
mechanical and the only kind the compiler knows about. It declares a 
rewrite rule that means "when you encounter a < between to instances of 
type T, rewrite it as a call to the the implements method of T if one 
exists, otherwise throw a compile-time error".
 
The other kind of meaning is unknown to the compiler but shared by humans 
and library functions.  It is an implied semantics something like "this is 
a predicate testing the most natural ordering of whatever type implements 
it".

The utility of tying contracts to overloading is that we have a 
well-defined set of expectations about the *semantics* of  various 
operators based on how they behave on primitive types. But the compiler 
does not and need not know about these expectations; they're expressed as 
conventions like "don't play stupid and overload < with a method that isn't 
anticommutative".  Or "don't overload + with a noncommutative operation".

The motivation for my proposal is that I think 90% of what people want to 
want a contract system for can be expressed by conventions about what kinds 
of actual method  you bind under a particular operator.  I agree that "a << 
os.Stdout" would be an ugly mistake, but it's not the compiler's job to 
enforce what can really only be made normative by a healthy culture 
surrounding the language.

(Also, does this mean the compiler wouldn't be able to make any 
> optimization assumptions regarding whether an operation is 
> commutative/associative/distributive?) 
>

How does trying to make  such assumptions gain anything when the operator 
compiles to a method call?  Serious question; I'm not seeing it.

-- 
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-16 16:37:01)

> you either compile "a < b" using the "implements <" method of the
> concrete type or throw an error.

>  This means that a change in the generic function, which happens to
>  introduce a new use of the parameter, can cause a failure at the
>  call
>  site, which may be far away.
>
> That doesn't seem to me to entail more risk than *any* change to the
> generic function would.

The trouble is that (in the case where you compile using the implements
<, rather than throwing an error) the type signature no longer tells you
what the constraints actually are; this information is only in the body
of the function, so it's easy to accidentally change it when changing
something that you think is just implementation detail.

-- 
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 Tuesday, October 16, 2018 at 4:17:36 PM UTC-4, Ian Denhardt wrote:
>
> What is this intended to buy us? Is this as Ian T suggests in lieu of 
> any kind of contract system? 


Oh , no.  You *need* a contract system (or at least my implements clause) 
so you can know if a < b has a meaning when a and b are non-primitive types.
 

> I outlined a similar thing in another thread, where you use a lexical 
> convention to distinguish type variables from concrete types, so you 
> don't need an explicit parameter list.


I will admit that this is my fallback position if deducing any-type 
arguments from the unboundedness of the type identifier is too brash for 
this crew,  That is, some kind of lexical marking of generic arguments 
seems to me greatly preferable to the Taylor/Griesemer syntax, which (with 
due respect to those two gentlemen)   I think is just plain ugly.

 

>
>

-- 
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 Dave MacFarlane (2018-10-16 16:40:59)

> (Also, does this mean the compiler wouldn't be able to make any
> optimization assumptions regarding whether an operation is
> commutative/associative/distributive?)

This is true regardless, because we aren't actually *enforcing* these
properties; they're just methods. So the compiler can't rely on them any
more than it can rely on implementations of io.Writer following the
rules written in English in thedocs. As I mentioned in my other message,
we should have a clear agreement on what these operators should mean,
but the compiler won't know about it.

I agree with your other points.

-- 
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

[Dave MacFarlane]

On Tue, Oct 16, 2018 at 4:14 PM Eric Raymond  wrote:
> If the alternative is requiring programmers to remember pre-cooked 
> relationships between different operators that may or may not be appropriate 
> for what he or she is trying to model, then I embrace this "problem".
>
> It's up to the programmer to implement things like commutativity.  I don't 
> think the language should pre-specify whether < is a partial or total 
> ordering.  Any choice of this kind the language makes will inevitably turn 
> out wrong a significant percentage of the time.  For proper orthogonality we 
> should not specify as much as we can about each operator, but as *little* as 
> we can and still have readable code.
>
> I would say the contract for < is just "takes operands of the same 
> unspecified type; returns a bool".  The fact that this will usually be used 
> to express an order for sorting, and that it is anticommutative, is none of 
> the compiler's business.  It's a convention that libraries will observe and 
> programmers know about, but that's a different matter.
>

Now I'm confused about what problem regarding generics you're trying
to solve with operator overloading. If you can't assume anything about
the meaning of an operator other than "it returns a bool", how could a
programmer use them in a generic contract? Or were you suggesting
operator overloading *instead of* contracts that exist in the current
proposal? (Even in that case, how would a programmer use them in a
generic function without their meaning being well defined?)

(Also, does this mean the compiler wouldn't be able to make any
optimization assumptions regarding whether an operation is
commutative/associative/distributive?)

- Dave

-- 
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] Issue with creating file on aws lambda

[Jim Ancona]

I'm pretty sure that the only writeable file system on Lambda in under
/tmp. You're not checking the error return from os.MkdirAll, but that call
is probably failing before you get to os.Create. Also keep in mind that
each Lambda instance is limited to 512 MB of /tmp space:
https://docs.aws.amazon.com/lambda/latest/dg/limits.html

Jim

On Tue, Oct 16, 2018 at 3:46 PM AE  wrote:

> Hello,
>
> I am trying to make function which will down file fro aws s3 and do some
> image resizing. I am having issue with os.Create, when I run locally on ec2
> machine it works fine but when I run on lambda directly I get error file
> not found
>
>
> package main
> import (
> "github.com/aws/aws-sdk-go/aws"
> "github.com/aws/aws-sdk-go/aws/session"
> "github.com/aws/aws-sdk-go/service/s3"
> "github.com/aws/aws-sdk-go/service/s3/s3manager"
> _ "github.com/aws/aws-lambda-go/lambda"
> _ "github.com/nfnt/resize"
>_ "image/jpeg"
> "fmt"
> "os"
>
> )
> type MyEvent struct {
> Name string `json:"name"`
> }
>
> func HandleRequest() (string, error) {
> runResize(
> "5bba5c0f01e2f_dcadcc7139454bf6dba4cbd01a7c92f8.jpeg")
> return fmt.Sprintf("Hello"), nil
> }
>
> func main() {
>  //   lambda.Start(HandleRequest)
> runResize("5bba5c0f01e2f_dcadcc7139454bf6dba4cbd01a7c92f8.jpeg")
>
> }
>
> func runResize(item_name string) {
> bucket := "bucket"
> folder_name := "images/users/original/"
> folder_name_220x220 := "images/users/220x220/"
> folder_name_250x250 := "images/users/250x250/"
> folder_name_500x500 := "images/users/500x500/"
> folder_name_large := "images/users/large/"
>
>
>
>
> createFolder(folder_name)
> createFolder(folder_name_220x220)
> createFolder(folder_name_250x250)
> createFolder(folder_name_500x500)
> createFolder(folder_name_large)
>
>
>
> item := folder_name + item_name
>
> fmt.Printf("Creating file %q \n", item)
> file, err :=  os.Create(item)
>
> if err != nil {
>
> exitErrorf("Unable to open file %q", err)
>
> }
> defer file.Close()
> sess, _ := session.NewSession({
> Region: aws.String("us-east-1")},
> )
> downloader := s3manager.NewDownloader(sess)
> numBytes, err := downloader.Download(file,
> {
> Bucket: aws.String(bucket),
> Key:aws.String(item),
> })
>
> if err != nil {
>
> exitErrorf("Unable to download item %q, %v", item, err)
>
> }
>fmt.Println("Processed", file.Name(), numBytes, "bytes")
> }
> func createFolder(folder_name string) {
> if _, err := os.Stat(folder_name); os.IsNotExist(err) {
> os.MkdirAll(folder_name, os.ModePerm)
> fmt.Printf("Folder created %q \n", folder_name)
> }
> }
>
> func exitErrorf(msg string, args ...interface{}) {
>
> fmt.Fprintf(os.Stderr, msg+"\n", args...)
>
> os.Exit(1)
>
> }
>
>
>
> Here how I build the code for deployment
>
>
> GOOS=linux go build -v -ldflags '-d -s -w' -a -tags netgo -installsuffix
> netgo -o resize && zip deployment.zip resize
>
>
> and error I am getting
>
>
> Unable to open file "open
> images/users/original/5bba5c0f01e2f_dcadcc7139454bf6dba4cbd01a7c92f8.jpeg:
> no such file or directory"
>
> This error i thrown on create on in LAMBDA
>
>
>
> Thanks
>
> --
> 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] Generics: an unwelcome conclusion and a proposal

[Eric Raymond]

On Tuesday, October 16, 2018 at 4:03:16 PM UTC-4, Ian Lance Taylor wrote:
>
> It's a feasible approach.  But unless I misunderstand, testing 
> arguments at the call site means that you've discarded contracts. 
>

I don't understand that claim. A contract (in my plan, an "implements" 
clause) is how you decide whether binding a template formal to a concrete 
type at the callsite makes sense .  For example, if the generic function 
has the signature "func foo( a T, b T)" and contains the expression " a < 
b" and you bind the unspecified type T to a a concrete one based on the 
arguments passed to foo at callsite, you either compile "a < b" using the 
"implements <" method of the concrete type or throw an error.
 

> This means that a change in the generic function, which happens to 
> introduce a new use of the parameter, can cause a failure at the call 
> site, which may be far away. 


That doesn't seem to me to entail more risk than *any* change to the 
generic function would.
 

>  It's 
> possible that that is the best way 
> forward.  But it's problematic, for the reasons discussed at the "type 
> contracts" section of the design draft.  This is less of a problem in 
> a dynamic language like LISP than it is in a nominally 
> compile-time-type-safe language like Go. 
>

Can you exhibit any scenario in which, under my plan, any validity check 
has to wait until runtime?

If it helps, think of an "implements <" method as a text-rewrite rule that 
is evaluated before code generation.  Anywhere you see "a < b" and the 
operand type has an "implements <" method, the expression is effectively 
replaced by a method call.

-- 
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-16 16:14:46)

>It's up to the programmer to implement things like commutativity.�  I
>don't think the language should pre-specify whether < is a partial or
>total ordering.�  Any choice of this kind the language makes will
>inevitably turn out wrong a significant percentage of the time.�  For
>proper orthogonality we should not specify as much as we can about each
>operator, but as *little* as we can and still have readable code.
>I would say the contract for < is just "takes operands of the same
>unspecified type; returns a bool".

> The fact that this will usually be used to express an order for sorting,
> and that it is anticommutative, is none of the compiler's business.
> It's a convention that libraries will observe and programmers know
> about, but that's a different matter.

What I'm getting at is that we should come to an agreement re: what
these conventions should be. e.g, with io.Writer, the compiler just
knows about:

type Writer interface {
Write(p []byte) (n int, err error)
}

But the docs also say:

Writer is the interface that wraps the basic Write method.

Write writes len(p) bytes from p to the underlying data stream. It returns
the number of bytes written from p (0 <= n <= len(p)) and any error
encountered that caused the write to stop early. Write must return a non-nil
error if it returns n < len(p). Write must not modify the slice data, even
temporarily.

Implementations must not retain p.

My point is just that we need to have a blurb like this somewhere for
each operator we allow to be overloaded; I don't want to see `os.Stdout
<< "Hello, World!"`. And when considering which operators we should
allow to be overloaded, we should consider what the corresponding blurb
should say, and whether it describes something that actually makes sense
to overload.

Given that we'll want a concrete "meaning" for e.g. `<`, even if
only by convention, I don't see that there's any legitimate use for
overloading `>` separately; if `x < y != y > x`, then something is
wrong.

-- 
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 Ian Lance Taylor (2018-10-16 16:02:57)
> On Tue, Oct 16, 2018 at 8:39 AM, Eric Raymond  wrote:
> >
> > New rule: A function on variables of undefined formal-argument types
> > compiles to a template (not a textual template - we don't want identifier
> > capture).  At each callsite of the function, the undefined types in the
> > formals are bound to the types of the arguments in the call. If every
> > operation in the resulting code is defined, the code compiles as if the
> > generic function had been written with the actual argument types at the
> > callsite.  If not, the compiler throws an error on each undefined operation.

What is this intended to buy us? Is this as Ian T suggests in lieu of
any kind of contract system? Or is it just to reduce verbosity in type
declarations? Or both?

If it's the former I agree with Ian T's complaint that this makes the
contract brittle. If it's the latter, we could just say that undefined
formals have no constraints, and so any use of them that depends on
something that not all types support is an error. I'm still not in love
with this, as I expect obscure error messages when someone makes a typo,
or accidentally being generic when you didn't mean to.

I outlined a similar thing in another thread, where you use a lexical
convention to distinguish type variables from concrete types, so you
don't need an explicit parameter list. But this was in the context of
someone having suggested just not supporting bounded type parameters at
all, so the question of where you write the bounds didn't come up (and I
still think bounds are important).

I also still think we should just use interfaces; elsewhere in this
thread I linked to my proposal about this, which when you add operator
overloading using Eric's solution to the `==` semantics problem covers
every concrete issue I've seen raised so far.

-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] Remove path from error messages

[Ian Lance Taylor]

On Tue, Oct 16, 2018 at 11:57 AM, Rich  wrote:
> Hi and Thanks Peter for your reply!  I have compiled this on my mac, and am
> running it on a linux system.  I compile it like this:
>
> GOOS=linux GOARCH=amd64 go build  -o binaries/linux64/mysqlrun mysqlrun.go
>
> Then I copy that binary to the server I am running it on and if there is an
> error -- it spits out an error message containing the path and the line
> number.  I've notice this happens with any program. OK this is only an
> example to show the error message. If you've got a program:
> package main
>
> import (
> "fmt"
> "strconv"
> )
>
> func main() {
> var divByS string
> fmt.Println("What do you want to divide by?")
> fmt.Printf("Number: ")
> fmt.Scanln()
> fmt.Println("Great, divide 100 by " + divByS)
> divBy, err := strconv.Atoi(divByS)
> if err != nil {
> fmt.Printf("OOOpps %v\n", err)
> }
> x := 100 / divBy
> fmt.Println(x)
> }
>
> yes I know it's easy to catch a divide by zero, but it's to show the
> error... When I run this:
>
> What do you want to divide by?
> Number: 0
> Great, divide 100 by 0
> panic: runtime error: integer divide by zero
>
> goroutine 1 [running]:
> main.main()
> /Users/rich/go/test.go:18 +0x2cf
>
> I don't want the highlighted part to print.

go build -gcflags=-trimpath=/Users/rich/go

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] Generics: an unwelcome conclusion and a proposal

[Eric Raymond]

(Sorry about the post fragment that got away from me.)

On Tuesday, October 16, 2018 at 3:33:58 PM UTC-4, Ian Denhardt wrote:
>
>
> The alternative though is having to implement several different methods 
> with obvious implementations in terms of one another, and make sure 
> they're consistent.


If the alternative is requiring programmers to remember pre-cooked 
relationships between different operators that may or may not be 
appropriate for what he or she is trying to model, then I embrace this 
"problem".

It's up to the programmer to implement things like commutativity.  I don't 
think the language should pre-specify whether < is a partial or total 
ordering.  Any choice of this kind the language makes will inevitably turn 
out wrong a significant percentage of the time.  For proper orthogonality 
we should not specify as much as we can about each operator, but as 
*little* as we can and still have readable code.

I would say the contract for < is just "takes operands of the same 
unspecified type; returns a bool".  The fact that this will usually be used 
to express an order for sorting, and that it is anticommutative, is none of 
the compiler's business.  It's a convention that libraries will observe and 
programmers know about, but that's a different matter.


-- 
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 Lance Taylor]

On Tue, Oct 16, 2018 at 8:39 AM, Eric Raymond  wrote:
>
> New rule: A function on variables of undefined formal-argument types
> compiles to a template (not a textual template - we don't want identifier
> capture).  At each callsite of the function, the undefined types in the
> formals are bound to the types of the arguments in the call. If every
> operation in the resulting code is defined, the code compiles as if the
> generic function had been written with the actual argument types at the
> callsite.  If not, the compiler throws an error on each undefined operation.
>
> (Of course, operation definitions forward through "implements" clauses.)
>
> What could be simpler than that?  No additional syntax, and it's easy to
> model in your head   There's precedent for it working; I'm an old LISPer and
> in that world what I just said can be summarized as "a function with a
> formal of unspecified type acts like  a hygienic macro".
>
> Before we tackle the graph example, let's examine this new compilation rule
> for traps. Call me crazy, but I think we just got parametric polymorphism
> with zero additional complexity load on the rest of the language.  Yes,
> compiling those templates in such a way that they can be instantiated at
> callsites from the compiled version will be interesting, but there's an
> obvious trick where you substitute pass-by-pointer-reference-to-the-stack
> for pass-by-value in order to make every reference to an argument have
> constant width regardless of what its concrete type is.  You're probably
> already doing something similar for interfaces.
>
> As the meme goes, "Prove me wrong".  If nobody does, we now have both
> parametric polymorphism and a complementary contract system at the cost of
> one (1) new keyword and (1) interaction with the rest of the design -
> overloading pointer types has to be forbidden in order not to break ==. .

It's a feasible approach.  But unless I misunderstand, testing
arguments at the call site means that you've discarded contracts.
This means that a change in the generic function, which happens to
introduce a new use of the parameter, can cause a failure at the call
site, which may be far away.  It's possible that that is the best way
forward.  But it's problematic, for the reasons discussed at the "type
contracts" section of the design draft.  This is less of a problem in
a dynamic language like LISP than it is in a nominally
compile-time-type-safe language like Go.

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] Generics: an unwelcome conclusion and a proposal

[Ian Denhardt]

Quoting Eric Raymond (2018-10-16 15:57:49)
>I don't undetstand rte q

rte q? I assume this is a typo, but I'm not sure what it was supposed to
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: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

[Matthias Schmidt]

Thanks for giving it a go!

cheers,

Matthias

Am Dienstag, 16. Oktober 2018 13:32:20 UTC+2 schrieb Thorsten Sommer:
>
> Thank you Matthias, for sharing your work. I find your password manager 
> useful. Keep the good work.
>
> Am Sonntag, 14. Oktober 2018 17:49:04 UTC+2 schrieb Matthias Schmidt:
>>
>> Hi Gophers,
>>
>> I’ve created a command line password manager in the style of the “pass” 
>> utility by Jason A. Donenfeld (https://www.passwordstore.org/) in Go.
>>
>> It uses symmetric AES encryption, Argon2 key-derivation and key-agent 
>> similar to SSH. 
>>
>> I would love to get your opinions on the code, the architecture, the 
>> security concept and perhaps more users on the codebase to find possible 
>> errors.
>>
>> Any comments, help and pull requests are welcome.
>>
>> https://github.com/ms140569/loki
>>
>> Cheers,
>>
>> Matthias Schmidt
>>
>>

-- 
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 Tuesday, October 16, 2018 at 3:33:58 PM UTC-4, Ian Denhardt wrote:
>
>
> The partial vs. total order thing brings up another issue that I think 
> needs to be kept in mind: what are the contracts for the various 
> operators? 
>

I don't undetstand rte q

-- 
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

[Matthias Schmidt]

And here it is:

https://github.com/ms140569/loki/releases/tag/1.2.0

Thanks to your guy's input the key-agent should be now way more secure.

cheers,

Matthias

Am Dienstag, 16. Oktober 2018 20:31:42 UTC+2 schrieb Matthias Schmidt:
>
> Hi Christopher + Eric,
>
> thanks for your feedback. You are right, i really underestimated the risk 
> of such attacks.
>
> I will lock the key-holding memory in the next release.
>
> cheers,
>
> Matthias
>
>
> Am Montag, 15. Oktober 2018 23:13:32 UTC+2 schrieb 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] Issue with creating file on aws lambda

[AE]

Hello,

I am trying to make function which will down file fro aws s3 and do some 
image resizing. I am having issue with os.Create, when I run locally on ec2 
machine it works fine but when I run on lambda directly I get error file 
not found 


package main
import ( 
"github.com/aws/aws-sdk-go/aws" 
"github.com/aws/aws-sdk-go/aws/session" 
"github.com/aws/aws-sdk-go/service/s3" 
"github.com/aws/aws-sdk-go/service/s3/s3manager" 
_ "github.com/aws/aws-lambda-go/lambda" 
_ "github.com/nfnt/resize" 
   _ "image/jpeg" 
"fmt" 
"os" 

) 
type MyEvent struct { 
Name string `json:"name"` 
}

func HandleRequest() (string, error) { 
runResize("5bba5c0f01e2f_dcadcc7139454bf6dba4cbd01a7c92f8.jpeg") 
return fmt.Sprintf("Hello"), nil 
} 

func main() { 
 //   lambda.Start(HandleRequest) 
runResize("5bba5c0f01e2f_dcadcc7139454bf6dba4cbd01a7c92f8.jpeg") 

} 

func runResize(item_name string) { 
bucket := "bucket" 
folder_name := "images/users/original/" 
folder_name_220x220 := "images/users/220x220/" 
folder_name_250x250 := "images/users/250x250/" 
folder_name_500x500 := "images/users/500x500/" 
folder_name_large := "images/users/large/" 


 

createFolder(folder_name) 
createFolder(folder_name_220x220) 
createFolder(folder_name_250x250) 
createFolder(folder_name_500x500) 
createFolder(folder_name_large) 

 

item := folder_name + item_name 

fmt.Printf("Creating file %q \n", item) 
file, err :=  os.Create(item) 

if err != nil { 

exitErrorf("Unable to open file %q", err) 

} 
defer file.Close() 
sess, _ := session.NewSession({ 
Region: aws.String("us-east-1")}, 
) 
downloader := s3manager.NewDownloader(sess) 
numBytes, err := downloader.Download(file, 
{ 
Bucket: aws.String(bucket), 
Key:aws.String(item), 
}) 

if err != nil { 

exitErrorf("Unable to download item %q, %v", item, err) 

} 
   fmt.Println("Processed", file.Name(), numBytes, "bytes")  
} 
func createFolder(folder_name string) { 
if _, err := os.Stat(folder_name); os.IsNotExist(err) { 
os.MkdirAll(folder_name, os.ModePerm) 
fmt.Printf("Folder created %q \n", folder_name) 
} 
} 

func exitErrorf(msg string, args ...interface{}) { 

fmt.Fprintf(os.Stderr, msg+"\n", args...) 

os.Exit(1) 

}



Here how I build the code for deployment


GOOS=linux go build -v -ldflags '-d -s -w' -a -tags netgo -installsuffix 
netgo -o resize && zip deployment.zip resize


and error I am getting 


Unable to open file "open 
images/users/original/5bba5c0f01e2f_dcadcc7139454bf6dba4cbd01a7c92f8.jpeg: 
no such file or directory"

This error i thrown on create on in LAMBDA



Thanks 

-- 
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]

Maybe we're talking about different things. Are you thinking of TOTP
2FA tokens? Your arguments do apply to those.

I'm not talking about those. I'm talking about devices like a yubikey,
which is essentially a  a poor person's HSM.
On Mon, Oct 15, 2018 at 7:21 PM robert engels  wrote:
>
> 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.
>


-- 
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] Generics: an unwelcome conclusion and a proposal

[Ian Denhardt]

Quoting Eric Raymond (2018-10-16 13:41:47)
>On Tuesday, October 16, 2018 at 1:23:20 PM UTC-4, Dave MacFarlane
>wrote:
>
> [...]
>
>  Would there be any rules defined for relationships between
>  operators?
>  For instance, if the "<" operator is defined does "<=" come for free
>  or does it require a separate overloading? (If so, what about ">"?)
>

>Good�  heavens, no - < doesn't imply a definition of >.�  That kind of
>spooky side effect would be extremely un-Go-like.

The alternative though is having to implement several different methods
with obvious implementations in terms of one another, and make sure
they're consistent. IMO this is worse than `x > y` desugaring to `y
< x`, which at least you can't screw up. `==` is fiddly here, since you
want to be able to define it without implementing `<`, but if you have
`<` (and we assume it is a total order), it fully determines what `==`
should do.

>Besides, you don't want it. There are lots of uses for partial
>orderings.

The partial vs. total order thing brings up another issue that I think
needs to be kept in mind: what are the contracts for the various
operators? Right now we don't have to be too explicit about what +, *,
<, == etc. mean in general, because we have a fixed finite number of
them, so we don't have to have a general meaning. If we allow
overloading e.g. `<`, we need to be clear on whether it's a partial or
total order.

I actually think we should require a total order, as all of the existing
implementations are total orders (except floats, which violate every
rule you might want to believe about numbers...), total orders are
likely to be the norm, and I would expect a partial order to catch
someone off guard. Most of the existing examples assume a total order.

Similar issues come up with the arithmetic operators. For example, must
`*` be commutative? If so, then matrix multiplication should not use
`*`.

Also, right now we have `+` defined on both numbers and strings. What
does this operator mean in the general sense? The most specific things I
can identify to say about it is that:

1. It is associative.
2. The zero value is an identity on both sides.

This is called a Monoid in abstract algebra. It is far from useless; for
example, it's exactly the structure you want for map-reduce (though that
would be horribly inefficient on strings).  But it's also super
abstract, and I think not the sort of interface we should have on
built-ins in Go.

I think there are solutions to all of these things, but they require
careful consideration. Importantly, we have to figure out where and how
we're going to document these rules so that people actually see and
understand them. It's not enough for us to have a thing buried in the
spec that `*` should be commutative; the author of that matrix library
has to see 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] Replacing the current go process with os.execvpe

[Mirko Friedenhagen]

Thanks, syscall.Exec seems to be what I want then.

Am Dienstag, 16. Oktober 2018 17:02:46 UTC+2 schrieb Ian Lance Taylor:
>
> On Tue, Oct 16, 2018 at 7:13 AM, Mirko Friedenhagen 
> > wrote: 
> > 
> > I am on my way to replace a Python script which writes several 
> configuration 
> > files before replacing itself with another program (e.g. bash). For that 
> I 
> > use https://docs.python.org/3/library/os.html#os.execv. 
> > 
> > Is there any equivalent in Golang? I do not use any fancy go routines in 
> the 
> > script, the only output are some log lines. Is it OK to just call 
> something 
> > like `syscall.Exec("/bin/bash", args, os.Environ())` 
>
> Yes, syscall.Exec seems like the closest equivalent.  It only works on 
> Unix systems. 
>
> 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] Re: Go standard library documentation for older Go versions

[Alan Conway]

Thanks for the helpful suggestions! The GO docs do indeed have a version on
the right edge of the screen, I completely failed to see it. Exactly what I
wanted. Also I appreciate the tip about downloading local sources, that's
always handy. Sorry for the noise.

On Tue, Oct 16, 2018 at 2:44 PM Jan Mercl <0xj...@gmail.com> wrote:

> On Tue, Oct 16, 2018 at 8:39 PM Agniva De Sarker <
> agniva.quicksil...@gmail.com> wrote:
>
> > It already does. Example - https://golang.org/pkg/net/http/#SameSite
>
> I cannot see anything like "introduced in version" at that page? Anyone
> knows why? (Using Chrome Verze 69.0.3497.100 (Oficiální sestavení)
> (64bitový))
> --
>
> -j
>
> --
> 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/ZLnpGoYL7X0/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] Generics with adaptors

[Ian Denhardt]

I write this kind of code a lot when working in Elm (whose generics are
in a similar spot to the place you suggest). It's not the worst, and
there various approaches in related languages use to make the "adaptors"
more ergonomic.

I still like the idea of using interfaces to express constraints better,
but I think it's worth discussing where this might go. Some
observations:

* We don't actually need an adaptor for the zero value, since we can
  just declare a variable of the generic type:

func MyFn(type T) {
// x is the zero value, per usual initialization rules:
var x T

// ...
}
* If we don't have any kind of bounding on type variables, then we can
  actually omit type parameter lists entirely, and use a lexical
  convention to distinguish between concrete and generic types. OCaml
  does this by denoting type parameters with a single quote, so 't is a
  type variable while t is a concrete type. Borrowing that convention we
  could write e.g:

func MapSlice(slice []'src, f func('src) 'dst) []'dst {
// ...
}

  ...which reduces verbosity a bit.

  Haskell and Elm both use case to distinguish, with uppercase variable
  names being concrete and lower case being type variables. I like that
  a bit better, but Go already uses case to distinguish exported vs.
  private.
* Your suggestion of default adaptors is similar to Scala's implicit
  parameters: https://docs.scala-lang.org/tour/implicit-parameters.html

One problem with this design, which bounding solves: Suppose we have a
generic set type implemented using binary trees (I will use
the 't notation discussed above, but you could use explicit parameter
lists as well).

type Order('t) interface{
Less(x, y 't)
}

type Set('t) struct {
// ...
}

func (s Set('t)) Insert('t; Order('t))
func (s Set('t)) Member('t; Order('t)) bool
// etc.

What happens if we accidentally pass different adapters to different
calls to the methods? e.g:


type CaseSensitive struct {}
type CaseInensitive struct {}

func (CaseSensitive) Less(l, r string) bool
func (CaseInsensitive) Less(l, r string) bool

// ...

var set Set(string)

set.Insert("Apple"; CaseInensitive{})
set.Insert("Animal"; CaseInsensitive{})
set.Insert("acorn"; CaseInsensitive{})

// Returns false!
set.Member("acorn"; CaseSensitive{})

Depending on scoping issues and how you infer the adaptors, this could
happen by accident, because of different adaptors being visible in
different scopes.

This is a known problem with scala implicits, whereas with rust
traits/haskell type classes, we're able to guarantee that there is only
one instance of an "adaptor" for a given type. But this means giving up
on automatic interface satisfaction, which is... no.

There's a paper that you'll find if you google "ocaml modular implicits"
that solves this issue for OCaml using OCaml's module system, and while
I have some ideas about how we *could* extend Go with the necessary
functionality, it's a much bigger change to the language than adding
bounds based on interfaces.

Quoting Patrick Smith (2018-10-16 06:33:39)
>Yet another generics discussion
>at� [1]https://gist.github.com/pat42smith/ccf021193971f6de6fdb229d68215
>302
>This one looks at what programmers would be able to do if very basic
>generics were added to Go, without contracts. Generic functions may not
>use methods or operators of their type parameters.
>The answer is quite a lot, actually. The code would be verbose, but not
>impossibly so.
>
>--
>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 [2]golang-nuts+unsubscr...@googlegroups.com.
>For more options, visit [3]https://groups.google.com/d/optout.
>
> Verweise
>
>1. https://gist.github.com/pat42smith/ccf021193971f6de6fdb229d68215302
>2. mailto:golang-nuts+unsubscr...@googlegroups.com
>3. 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] Remove path from error messages

[Rich]

Hi and Thanks Peter for your reply!  I have compiled this on my mac, and am 
running it on a linux system.  I compile it like this:

GOOS=linux GOARCH=amd64 go build  -o binaries/linux64/mysqlrun mysqlrun.go

Then I copy that binary to the server I am running it on and if there is an 
error -- it spits out an error message containing the path and the line 
number.  I've notice this happens with any program. OK this is only an 
example to show the error message. If you've got a program:
package main

import (
"fmt"
"strconv"
)

func main() {
var divByS string
fmt.Println("What do you want to divide by?")
fmt.Printf("Number: ")
fmt.Scanln()
fmt.Println("Great, divide 100 by " + divByS)
divBy, err := strconv.Atoi(divByS)
if err != nil {
fmt.Printf("OOOpps %v\n", err)
}
x := 100 / divBy
fmt.Println(x)
}

yes I know it's easy to catch a divide by zero, but it's to show the 
error... When I run this:

What do you want to divide by?
Number: 0
Great, divide 100 by 0
panic: runtime error: integer divide by zero

goroutine 1 [running]:
main.main()
/Users/rich/go/test.go:18 +0x2cf

I don't want the highlighted part to print.

On Tuesday, October 16, 2018 at 2:35:17 PM UTC-4, Peter Bourgon wrote:
>
> Error messages don't include any contextual information by default. If 
> the path to a Go file is in there, it's because whatever created the 
> error message (or modified it at some point) put it there. Where is 
> that error created, and what touches it as it flows through the call 
> stack to the logging statement that prints it to the screen? Don't 
> forget to also check the logging package itself, which can sometimes 
> annotate with caller information. Trace that out, and you'll find your 
> answer. 
> On Tue, Oct 16, 2018 at 11:28 AM Rich > 
> wrote: 
> > 
> > I apologize if this has been asked before but I searched google and this 
> group and didn't find it.  How do you remove the path from the error 
> messages?  So I have a valid error: 
> > 
> > 2018/10/16 18:13:12 [error] in 
> main.checkMaster[/Users/rich/go/mysqlrun/mysqlrun.go:739] Error 1045: 
> Access denied for user 
> > 
> > How do I get rid of the part highlighted above? It's a valid error. The 
> user specified the wrong password so I want the error -- I just don't want 
> the path part as a part of that error.  This happens any time there is an 
> error in a script, it prints out information about the author that I don't 
> particularly want published. 
> > 
> > Thanks 
> > 
> > -- 
> > 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: Go standard library documentation for older Go versions

[Jan Mercl]

On Tue, Oct 16, 2018 at 8:39 PM Agniva De Sarker <
agniva.quicksil...@gmail.com> wrote:

> It already does. Example - https://golang.org/pkg/net/http/#SameSite

I cannot see anything like "introduced in version" at that page? Anyone
knows why? (Using Chrome Verze 69.0.3497.100 (Oficiální sestavení)
(64bitový))
-- 

-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.

Re: [go-nuts] Debian package for Go 1.11 on the way?

[Lasse Westh-Nielsen]

On Tue, Oct 16, 2018 at 4:12 PM Wojciech S. Czarnecki 
wrote:

> On Tue, 16 Oct 2018 01:57:17 -0700 (PDT)
> Lasse Westh-Nielsen  wrote:
>
> > Have been using https://github.com/golang/go/wiki/Ubuntu, does anybody
> know
> > if there is a 1.11 package on the way?
>
> wiki/Ubuntu says "The Go project's official download page is at
> https://golang.org/dl/.;
>
> There you'll find https://dl.google.com/go/go1.11.1.linux-amd64.tar.gz
> link.
>
> Uninsatll your ancient debian packages before.
>

Thanks Wojciech,

Do we know _why_ there used to be Debian packages, but no Debian packages
anymore? I for one thought them handy.

 - Lasse

-- 
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: Go standard library documentation for older Go versions

[Agniva De Sarker]

Online API docs are just for the latest release and the master branch. But 
if you have the version you want locally installed, you can just spin up 
godoc and point to the goroot and browse it.

> I would love it if the https://golang.org/pkg/ documentation had 
"introduced in version..." notations 

It already does. Example - https://golang.org/pkg/net/http/#SameSite



On Tuesday, 16 October 2018 20:08:10 UTC+5:30, aco...@redhat.com wrote:
>
> I have not been able to find online API doc for older Go standard library 
> versions, where would I find this? Apologies if it's in an obvious place 
> and I missed it.
>
> I would love it if the https://golang.org/pkg/ documentation had 
> "introduced in version..." notations like https://docs.python.org or 
> https://en.cppreference.com - but I'll settle for easy access to docs for 
> older versions.
>
> Minor nit: the release notes in the release history link to 
> https://golang.org/pkg/ which is not really correct. The latest version 
> could have made further changes to the API since that release which would 
> be confusing.
>
>

-- 
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] Remove path from error messages

[Peter Bourgon]

Error messages don't include any contextual information by default. If
the path to a Go file is in there, it's because whatever created the
error message (or modified it at some point) put it there. Where is
that error created, and what touches it as it flows through the call
stack to the logging statement that prints it to the screen? Don't
forget to also check the logging package itself, which can sometimes
annotate with caller information. Trace that out, and you'll find your
answer.
On Tue, Oct 16, 2018 at 11:28 AM Rich  wrote:
>
> I apologize if this has been asked before but I searched google and this 
> group and didn't find it.  How do you remove the path from the error 
> messages?  So I have a valid error:
>
> 2018/10/16 18:13:12 [error] in 
> main.checkMaster[/Users/rich/go/mysqlrun/mysqlrun.go:739] Error 1045: Access 
> denied for user
>
> How do I get rid of the part highlighted above? It's a valid error. The user 
> specified the wrong password so I want the error -- I just don't want the 
> path part as a part of that error.  This happens any time there is an error 
> in a script, it prints out information about the author that I don't 
> particularly want published.
>
> Thanks
>
> --
> 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

[Matthias Schmidt]

Hi Christopher + Eric,

thanks for your feedback. You are right, i really underestimated the risk 
of such attacks.

I will lock the key-holding memory in the next release.

cheers,

Matthias


Am Montag, 15. Oktober 2018 23:13:32 UTC+2 schrieb 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] Remove path from error messages

[Rich]

I apologize if this has been asked before but I searched google and this 
group and didn't find it.  How do you remove the path from the error 
messages?  So I have a valid error:

2018/10/16 18:13:12 [error] in 
main.checkMaster[/Users/rich/go/mysqlrun/mysqlrun.go:739] 
Error 1045: Access denied for user

How do I get rid of the part highlighted above? It's a valid error. The 
user specified the wrong password so I want the error -- I just don't want 
the path part as a part of that error.  This happens any time there is an 
error in a script, it prints out information about the author that I don't 
particularly want published.

Thanks

-- 
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 Tuesday, October 16, 2018 at 1:23:20 PM UTC-4, Dave MacFarlane wrote:
>
> Why is the implements keyword a better solution than magic names? 
>
 
Because you get syntactic uniformity with primitive types without claiming 
namespace you don't need.  It's more minimalist.

Would there be any rules defined for relationships between operators? 
> For instance, if the "<" operator is defined does "<=" come for free 
> or does it require a separate overloading? (If so, what about ">"?) 
>

Good  heavens, no - < doesn't imply a definition of >.  That kind of spooky 
side effect would be extremely un-Go-like.

Besides, you don't want it. There are lots of uses for partial orderings.

I would say >= is defined if and only if == and >= are defined and cannot 
be separately overloaded.  But I'd be open to argument on that point.

 

-- 
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

[Dave MacFarlane]

Why is the implements keyword a better solution than magic names?
Magic names feel more Go-ish to me in the sense that interface
implementations already eschew the implements keyword (unlike most
other languages) and don't require any syntactic changes to the
language.

Would there be any rules defined for relationships between operators?
For instance, if the "<" operator is defined does "<=" come for free
or does it require a separate overloading? (If so, what about ">"?)

On Mon, Oct 15, 2018 at 10:24 PM Eric Raymond  wrote:
>
> 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.



-- 
- Dave

-- 
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:24:59 PM UTC-4, alanfo wrote:
>
> With regard to your reply to Ian, I'm afraid I can't agree with you that 
> the type parameters shouldn't be specified 'up front'. That's just too 
> 'dynamic' for me and not very go-like. I'd imagine it would give the 
> compiler all sorts of problems and anyone reading the code would wonder 
> whether T, Node, Edge etc. were concrete types defined elsewhere in the 
> package or type parameters of a generic function.
>

So now we get to the philosophical issue.  Why and when do I *care* 
whether  I'm looking at a concrete type or type parameter? 

I maintain that normally I don't - it only matters to me what contract the 
type is expected to satisfy, and that should be clear from looking at its 
callsites.  If it isn't clear, that's a problem that heavier notation won't 
solve.

I've already thought of a compilation strategy for this. It's not a new 
problem; I had to think about a closely parallel case in Lisp around 1980.

-- 
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 Ian Lance Taylor (2018-10-16 09:44:00)

> It's not clear to me what other aspects of various generic proposals
> you are picking up here.  How are you imagining that we would write
> the function that merges two channels?  With the current design draft
> that looks something like this:
>
> ...
>
> Also, how do you write the graph example from the design draft, which
> uses two types?
>
> Ian

Through this discussion I'd been mentally grafting Eric's operator
solution to my own proposal, which uses interfaces instead of contracts
and just punts on operators entirely (due to the fiddly issue I brought
up re: pointers, which I hadn't come up with a solution for):

https://gist.github.com/zenhack/ad508d08c72fce6df945a49945ad826d

The graph example is the more interesting one, here's a direct link to
that solution:


https://gist.github.com/zenhack/ad508d08c72fce6df945a49945ad826d#mutually-referential-type-parameters

The channel example is the same as in the current draft; it doesn't use
contracts as-is, so is unaffected by either my own design or Eric's.20

I think Eric's solution is mostly orthogonal to what I discuss in the
above design, but solves the most unsatisfying things. I may try to
actually write up a version that incorporates it sometime next week.

-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.

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

[alanfo]

I'm not sure whether the likes of = and := would be classed as operators or 
punctuation in Go though the former is certainly an operator in C++ where 
(very confusingly IMO) it can be overloaded and sometimes is.

Although I wouldn't like to see these symbols overloaded in Go I don't have 
a problem with the assignment forms of basic operators: +=, *=, |= and the 
like. If the basic operator were overloaded then I think it should follow 
automatically that the assignment form should be overloaded as well.

Opinions will, of course, differ on which operators should permit 
overloading. My problem with the channel operator is that firstly it has 
two forms, send and receive, and secondly it is not a standard operator 
within the C family of languages - it's a Go special - and I think I'd find 
it very confusing if it were overloaded to perform other duties even if 
they were channel related.

The equality operators really are a thorny problem. If, for example, you 
decided to overload a struct so that it implemented the < operator based on 
the value of a single numeric field, this would then be inconsistent with 
the existing meaning of == where *all* the fields need to be equal. On the 
other hand, if you decided to allow == to be overloaded to be consistent 
with <, you might end up with a definition which was at odds with the 
standard use of this operator in map keys.

I don't think there's really a satisfactory answer to this apart from 
introducing new operators for 'ordered equality' outlandish though it may 
seem :)

With regard to your reply to Ian, I'm afraid I can't agree with you that 
the type parameters shouldn't be specified 'up front'. That's just too 
'dynamic' for me and not very go-like. I'd imagine it would give the 
compiler all sorts of problems and anyone reading the code would wonder 
whether T, Node, Edge etc. were concrete types defined elsewhere in the 
package or type parameters of a generic function.

Alan

On Tuesday, October 16, 2018 at 1:05:20 PM UTC+1, Eric Raymond wrote:

> On Tuesday, October 16, 2018 at 6:33:26 AM UTC-4, alanfo wrote:
>>
>> However, I think it's important to learn the lessons of the past and not 
>> follow languages such as C++ or Scala where you can overload virtually 
>> anything or even make up your own operators which can result in confusing 
>> or even write-only code.
>>
>
> Strongly agreed.   I too would be OK with only allowing a simple subset of 
> operators to be overloaded - excluding && and ||, notably; I wrote up that 
> possibility as a way of exploring the edges of the proposal. not as  a 
> serious amendment.
>
> On the other hand, I think it's important as a matter of good interface 
> psychology not to be arbitrary.  That is, having introduced "implements", 
> the question "why can't I overload operator foo" should always have an 
> answer that is principled and specific to a given operator.  For example, 
> we might disallow / because the relationship between its operand types and 
> result type is not obvious by inspection.
>
> That criterion might also be a principled way to knock out short-circuit 
> use of && and || on non-booleans.  On the other hand, I don't know that I 
> want to be quite that austere.  If someone said to me "I want to overload 
> <- for a struct wrapping a channel type, why is that excluded," I don't 
> think I'd have a satisfactory answer
>
> I would also disallow overloading of the =, :=, <-, ..., [], {}, () and 
>> yes - equality operators - as well because I believe to do otherwise would 
>> be very confusing. 
>>
>
> I wouldn't exclude ==.  Even if we have to have a special exclusion for 
> pointer types,  any generic/overloading system that didn't support that is 
> something most people who want generics would regard as a cruel tease.
>
> := is not an operator at all in Go (and nor is =), unless I'm missing 
> something basic.  I don't usually think of  [], {}, () as operators either, 
> though one could make a case for [] as a dyadic indexing/mapping operator.  
> I wouldn't be hostile to including that in the allowed set, but I wouldn't 
> cry if it were excluded either.
>
> Another possibility would be to introduce two new ordering operators, 
>> perhaps >< (for ==) and <> (for !=), which *could* be overloaded though 
>> the first of these would take some getting used to!
>>
>
> This is not keeping it simple. Excuse me, but I think you are now making 
> the sound of someone getting lost in the weeds. ;-)
>
> As for Eric's proposal - using an 'implements' keyword - I like it for the 
>> following reasons:
>>
>> 1. It avoids the need to make up a long list of names for the operators 
>> which folks either have to remember or look up in the spec.
>>
>> 2. It makes it easier to retrofit operator overloading to existing types 
>> for which suitable methods have already been defined.
>>
>> 3. As 'implements' would only be used in contexts which don't exist at 
>> present, it needn't be a 'full' keyword and 

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

[Wojciech S. Czarnecki]

On Tue, 16 Oct 2018 08:39:32 -0700 (PDT)
Eric Raymond  wrote:

> New rule: A function on variables of undefined formal-argument types 
> compiles to a template (not a textual template - we don't want identifier 
> capture).  At each callsite of the function, the undefined types in the 
> formals are bound to the types of the arguments in the call. If every 
> operation in the resulting code is defined, the code compiles as if the 
> generic function had been written with the actual argument types at the 
> callsite.  If not, the compiler throws an error on each undefined 
> operation. 

Sounds like implementation sketch of my CGG proposal at 
https://github.com/ohir/gonerics
(https://github.com/ohir/gonerics/blob/master/howdoes.md)

I am happy to see another soul that see there is no need for filling
type parameters at call site.

> Call me crazy, but I think we just got parametric polymorphism 
> with zero additional complexity load on the rest of the language.

I am eager to see one of CGG critics explaining to you that it is not
"because it is not how it is done in Java". ;)

> As the meme goes, "Prove me wrong".  If nobody does, we now have both 
> parametric polymorphism and a complementary contract system at the cost of 
> one (1) new keyword and (1) interaction with the rest of the design - 
> overloading pointer types has to be forbidden in order not to break ==. . 

Anyway, "Implements" is a form of contract. As much as CGG's "for type".
Ah, and CGG has one less new keyword ;) But I like your approach.
Right after mine's.

TC,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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: Debian package for Go 1.11 on the way?

[Tamás Gulácsi]

2018. október 16., kedd 14:38:08 UTC+2 időpontban Lasse Westh-Nielsen a 
következőt írta:
>
> Hey,
>
> Have been using https://github.com/golang/go/wiki/Ubuntu, does anybody 
> know if there is a 1.11 package on the way?
>
> Regards,
>
> Lasse
>
>
I use 'go get gopkg.in/niemeyer/godeb.v1/cmd/godeb' - it downloads and 
created a .deb file, which I can install.

-- 
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 Tuesday, October 16, 2018 at 9:44:23 AM UTC-4, Ian Lance Taylor wrote:
>
> It's not clear to me what other aspects of various generic proposals 
> you are picking up here.


The answer is "none of them".  That wasn't my goal, because all the 
previous generics proposals I have seen struck me as overcomplicated and 
un-Go-like. What I was attempting to demonstrate was something minimal and 
clean that would handle your smoke test and the common cases that people 
who say they want generics seem to want to cover, such as your smoke test - 
min and max - and reordering a slice of elements of a type with a sortable 
contract.

 How are you imagining that we would write 
> the function that merges two channels? 


Exactly as you did, except I would omit the type parameter.  It's 
unnecessary weight.

New rule: A function on variables of undefined formal-argument types 
compiles to a template (not a textual template - we don't want identifier 
capture).  At each callsite of the function, the undefined types in the 
formals are bound to the types of the arguments in the call. If every 
operation in the resulting code is defined, the code compiles as if the 
generic function had been written with the actual argument types at the 
callsite.  If not, the compiler throws an error on each undefined 
operation. 

(Of course, operation definitions forward through "implements" clauses.)
 
What could be simpler than that?  No additional syntax, and it's easy to 
model in your head   There's precedent for it working; I'm an old LISPer 
and in that world what I just said can be summarized as "a function with a 
formal of unspecified type acts like  a hygienic macro".

Before we tackle the graph example, let's examine this new compilation rule 
for traps. Call me crazy, but I think we just got parametric polymorphism 
with zero additional complexity load on the rest of the language.  Yes, 
compiling those templates in such a way that they can be instantiated at 
callsites from the compiled version will be interesting, but there's an 
obvious trick where you substitute pass-by-pointer-reference-to-the-stack 
for pass-by-value in order to make every reference to an argument have 
constant width regardless of what its concrete type is.  You're probably 
already doing something similar for interfaces.

As the meme goes, "Prove me wrong".  If nobody does, we now have both 
parametric polymorphism and a complementary contract system at the cost of 
one (1) new keyword and (1) interaction with the rest of the design - 
overloading pointer types has to be forbidden in order not to break ==. . 

-- 
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] Go standard library documentation for older Go versions

[Wojciech S. Czarnecki]

On Tue, 16 Oct 2018 07:38:09 -0700 (PDT)
acon...@redhat.com wrote:

> I have not been able to find online API doc for older Go standard library 
> versions, where would I find this? Apologies if it's in an obvious place 
> and I missed it.

Go library docs are sourced from the source, so all old docs are available 
locally. Just deep clone the go repo, checkout version you're interested in
then point godoc there. I'd suggest to copy repo for "docs purposes" to avoid
accidental mismatch at pull time to your main go sources (it needs to be at
master branch, not at detached head).

so:

cd $mirror_path

# possibly make local go repo mirror

git clone https://github.com/golang/go

rsync -a go go4doc

cd go4doc

git checkout go1.5

# Note: checking out 'go1.5' You are in 'detached HEAD' state...
# HEAD is now at bb03defe93... [release-branch.go1.5] go1.5

# look up fmt as it was of go1.5 on terminal

godoc -goroot $mirror_path/go4doc fmt

# or point godoc webserver there:

godoc -goroot $mirror_path/go4doc -http localhost:1515

# then browse docs at localhost:1515
# eg. http://localhost:1515/doc/devel/release.html
#
# Docs front page is of release that built godoc, but docs
# come from the  -goroot $mirror_path/go4doc

> but I'll settle for easy access to docs for older versions.

hope this helps,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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] Replacing the current go process with os.execvpe

[Jan Mercl]

On Tue, Oct 16, 2018 at 4:14 PM Mirko Friedenhagen 
wrote:

> Is it OK to just call something like `syscall.Exec("/bin/bash", args,
os.Environ())`

I'd recommend to first try exec.Command
.
-- 

-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.

Re: [go-nuts] Replacing the current go process with os.execvpe

[Ian Lance Taylor]

On Tue, Oct 16, 2018 at 7:13 AM, Mirko Friedenhagen
 wrote:
>
> I am on my way to replace a Python script which writes several configuration
> files before replacing itself with another program (e.g. bash). For that I
> use https://docs.python.org/3/library/os.html#os.execv.
>
> Is there any equivalent in Golang? I do not use any fancy go routines in the
> script, the only output are some log lines. Is it OK to just call something
> like `syscall.Exec("/bin/bash", args, os.Environ())`

Yes, syscall.Exec seems like the closest equivalent.  It only works on
Unix systems.

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.

[go-nuts] Go standard library documentation for older Go versions

[aconway]

I have not been able to find online API doc for older Go standard library 
versions, where would I find this? Apologies if it's in an obvious place 
and I missed it.

I would love it if the https://golang.org/pkg/ documentation had 
"introduced in version..." notations like https://docs.python.org or 
https://en.cppreference.com - but I'll settle for easy access to docs for 
older versions.

Minor nit: the release notes in the release history link to 
https://golang.org/pkg/ which is not really correct. The latest version 
could have made further changes to the API since that release which would 
be confusing.

-- 
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] Replacing the current go process with os.execvpe

[Mirko Friedenhagen]

Hello everybody,

I am on my way to replace a Python script which writes several 
configuration files before replacing itself with another program (e.g. 
bash). For that I use https://docs.python.org/3/library/os.html#os.execv.

Is there any equivalent in Golang? I do not use any fancy go routines in 
the script, the only output are some log lines. Is it OK to just call 
something like `syscall.Exec("/bin/bash", args, os.Environ())`

Regards
Mirko

-- 
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] Debian package for Go 1.11 on the way?

[Wojciech S. Czarnecki]

On Tue, 16 Oct 2018 01:57:17 -0700 (PDT)
Lasse Westh-Nielsen  wrote:

> Have been using https://github.com/golang/go/wiki/Ubuntu, does anybody know 
> if there is a 1.11 package on the way?

wiki/Ubuntu says "The Go project's official download page is at 
https://golang.org/dl/.; 

There you'll find https://dl.google.com/go/go1.11.1.linux-amd64.tar.gz link.

Uninsatll your ancient debian packages before.

> Lasse

hope this helps,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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 Lance Taylor]

On Mon, Oct 15, 2018 at 7:24 PM, Eric Raymond  wrote:
>
> 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?

It's not clear to me what other aspects of various generic proposals
you are picking up here.  How are you imagining that we would write
the function that merges two channels?  With the current design draft
that looks something like this:

func Merge(type E)(c1, c2 chan E) chan E {
r := make(chan E)
go func() {
for c1 != nil && c2 != nil {
select {
case v, ok = <-c1:
if !ok {
c1 = nil
} else {
r <- v
}
case v, ok := <-c2:
if !ok {
c2 = nil
} else {
r <- v
}
}
}
close(r)
}()
return r
}

Also, how do you write the graph example from the design draft, which
uses two types?

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] Temporary files in go

[Manuel Amador (Rudd-O)]

On 12/10/2018 12.35, Robert Engels wrote:
> Which is not Windows, which is giving up a lot of options, and is important 
> to some people, where as just using tmp files is ok. I am not even sure if 
> windows supports deleting an open file yet.

I believe the default behavior is no it does not.

-- 
Rudd-O
http://rudd-o.com/

-- 
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 with adaptors

[Eric Raymond]

On Tuesday, October 16, 2018 at 6:34:10 AM UTC-4, Patrick Smith wrote:
>
> Yet another generics discussion at 
> https://gist.github.com/pat42smith/ccf021193971f6de6fdb229d68215302
>
> This one looks at what programmers would be able to do if very basic 
> generics were added to Go, without contracts. Generic functions may not use 
> methods or operators of their type parameters.
>
> The answer is quite a lot, actually. The code would be verbose, but not 
> impossibly so.
>

Ingenious, but  I think it fails Ian Lance Taylor's smoke test. 

I also dislike the verbosity.

-- 
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] Debian package for Go 1.11 on the way?

[Lasse Westh-Nielsen]

Hey,

Have been using https://github.com/golang/go/wiki/Ubuntu, does anybody know 
if there is a 1.11 package on the way?

Regards,

Lasse

-- 
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 6:33:26 AM UTC-4, alanfo wrote:
>
> However, I think it's important to learn the lessons of the past and not 
> follow languages such as C++ or Scala where you can overload virtually 
> anything or even make up your own operators which can result in confusing 
> or even write-only code.
>

Strongly agreed.   I too would be OK with only allowing a simple subset of 
operators to be overloaded - excluding && and ||, notably; I wrote up that 
possibility as a way of exploring the edges of the proposal. not as  a 
serious amendment.

On the other hand, I think it's important as a matter of good interface 
psychology not to be arbitrary.  That is, having introduced "implements", 
the question "why can't I overload operator foo" should always have an 
answer that is principled and specific to a given operator.  For example, 
we might disallow / because the relationship between its operand types and 
result type is not obvious by inspection.

That criterion might also be a principled way to knock out short-circuit 
use of && and || on non-booleans.  On the other hand, I don't know that I 
want to be quite that austere.  If someone said to me "I want to overload 
<- for a struct wrapping a channel type, why is that excluded," I don't 
think I'd have a satisfactory answer

I would also disallow overloading of the =, :=, <-, ..., [], {}, () and yes 
> - equality operators - as well because I believe to do otherwise would be 
> very confusing. 
>

I wouldn't exclude ==.  Even if we have to have a special exclusion for 
pointer types,  any generic/overloading system that didn't support that is 
something most people who want generics would regard as a cruel tease.

:= is not an operator at all in Go (and nor is =), unless I'm missing 
something basic.  I don't usually think of  [], {}, () as operators either, 
though one could make a case for [] as a dyadic indexing/mapping operator.  
I wouldn't be hostile to including that in the allowed set, but I wouldn't 
cry if it were excluded either.

Another possibility would be to introduce two new ordering operators, 
> perhaps >< (for ==) and <> (for !=), which *could* be overloaded though 
> the first of these would take some getting used to!
>

This is not keeping it simple. Excuse me, but I think you are now making 
the sound of someone getting lost in the weeds. ;-)

As for Eric's proposal - using an 'implements' keyword - I like it for the 
> following reasons:
>
> 1. It avoids the need to make up a long list of names for the operators 
> which folks either have to remember or look up in the spec.
>
> 2. It makes it easier to retrofit operator overloading to existing types 
> for which suitable methods have already been defined.
>
> 3. As 'implements' would only be used in contexts which don't exist at 
> present, it needn't be a 'full' keyword and would therefore be backwards 
> compatible.
>

These points had occurred to me, though I did not make them explicit in my 
proposal.  In my invention process, the idea of using operator signatures 
as implied contracts came first. I was then searching for a way to restrict 
the parse context in which new syntax might collide with identifiers in 
existing code and came up with the "implements" clause and its location 
just before a method's leading { as a way to accomplish that restriction.
  

> One area that hasn't been addressed so far is conversions. To convert to 
> say, int64, I'd suggest 'implements int64()' and to convert from int64 
> perhaps 'implements T(int64)' where T is the method's receiver type. TBH, I 
> don't particularly like the idea of user-defined conversions at all but 
> they're probably inevitable if you want to have unified generic constraints 
> and at least they'd always be explicit.
>

I am neutral on whether the contract system should support conversions.  If 
the consensus is that they're needed, fine by me; if not, also fine by me.  
I do not regard either position as a hill that "implements" should die on.
 

> Subject to all this, I think it might well be possible to get rid of 
> contracts and just use interfaces for generic constraints.
>

That was more or less my goal.  All the contract proposals I have seen 
struck me as clever but overweight.
 

-- 
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

[Thorsten Sommer]

Thank you Matthias, for sharing your work. I find your password manager 
useful. Keep the good work.

Am Sonntag, 14. Oktober 2018 17:49:04 UTC+2 schrieb Matthias Schmidt:
>
> Hi Gophers,
>
> I’ve created a command line password manager in the style of the “pass” 
> utility by Jason A. Donenfeld (https://www.passwordstore.org/) in Go.
>
> It uses symmetric AES encryption, Argon2 key-derivation and key-agent 
> similar to SSH. 
>
> I would love to get your opinions on the code, the architecture, the 
> security concept and perhaps more users on the codebase to find possible 
> errors.
>
> Any comments, help and pull requests are welcome.
>
> https://github.com/ms140569/loki
>
> Cheers,
>
> Matthias Schmidt
>
>

-- 
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 with adaptors

[Beoran]

I kind of like this idea. Contracts seem likely to introduce all kinds of 
complexity, and with a bit more explicit code, just generics without 
contracts could work just fine. It's definitely the simplest implementation 
of generics that could work.

-- 
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

[alanfo]

One other advantage of Eric's proposal that has just occurred to me is that 
folks who dislike operator overloading wouldn't have to use it at all - 
they could just use the named methods.

The only people who would need to use it would be those writing unified 
generic functions/methods who would probably be a minority of users in any 
case.

Of course, all users would need some familiarity with the concept as they 
might need to read code written by others which did use it.

Alan

On Tuesday, October 16, 2018 at 11:33:26 AM UTC+1, alanfo wrote:
>
> Well, whatever you may think of it, there's no doubt that a lot of the 
> problems we currently have with generic constraints would go away if 
> operator overloading were introduced into Go 2.
>
> Personally, I wouldn't be dismayed if this were to happen. A lot of my 
> stuff is mathematical in nature and this is an area where operator 
> overloading works best - and indeed is expected - by programmers working in 
> these disciplines.
>
> However, I think it's important to learn the lessons of the past and not 
> follow languages such as C++ or Scala where you can overload virtually 
> anything or even make up your own operators which can result in confusing 
> or even write-only code.
>
> It is far better, in my view, just to permit the overloading of a limited 
> subset of operators and for their signature, priority etc. to mirror those 
> of the built-in ones.
>
> In particular, I agree with Ian that there would be very little value in 
> overloading the logical operators (&&, || and !) and that this should be 
> disallowed.
>
> I would also disallow overloading of the =, :=, <-, ..., [], {}, () and 
> yes - equality operators - as well because I believe to do otherwise would 
> be very confusing. 
>
> The equality operators (== and !=) have a well defined meaning in Go 1 
> which spans both built-in and user defined types and, to maintain backwards 
> compatibility, I don't think this should be changed. When you want to use 
> these operators purely for ordering purposes, they can always be reproduced 
> by a combination of the other ordering operators as I said in another 
> recent thread.
>
> If you can't overload == and != then 'comparable' (or whatever you want to 
> call it) would need to be a built-in interface.
>
> Another possibility would be to introduce two new ordering operators, 
> perhaps >< (for ==) and <> (for !=), which *could* be overloaded though 
> the first of these would take some getting used to!
>
> As for Eric's proposal - using an 'implements' keyword - I like it for the 
> following reasons:
>
> 1. It avoids the need to make up a long list of names for the operators 
> which folks either have to remember or look up in the spec.
>
> 2. It makes it easier to retrofit operator overloading to existing types 
> for which suitable methods have already been defined.
>
> 3. As 'implements' would only be used in contexts which don't exist at 
> present, it needn't be a 'full' keyword and would therefore be backwards 
> compatible.
>
> One area that hasn't been addressed so far is conversions. To convert to 
> say, int64, I'd suggest 'implements int64()' and to convert from int64 
> perhaps 'implements T(int64)' where T is the method's receiver type. TBH, I 
> don't particularly like the idea of user-defined conversions at all but 
> they're probably inevitable if you want to have unified generic constraints 
> and at least they'd always be explicit.
>
> Subject to all this, I think it might well be possible to get rid of 
> contracts and just use interfaces for generic constraints.
>
> Incidentally, I'm not a fan of wrapping types so that they can support the 
> built-in operators. Although this is easy enough for scalar types, when you 
> have slices, maps etc. of such types it's a different kettle of fish as 
> wrapping/unwrapping requires a lot more code.
>
> Alan
>
> On Tuesday, October 16, 2018 at 3:24:50 AM UTC+1, Eric Raymond wrote:
>>
>> 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 

[go-nuts] Generics with adaptors

[Patrick Smith]

Yet another generics discussion at
https://gist.github.com/pat42smith/ccf021193971f6de6fdb229d68215302

This one looks at what programmers would be able to do if very basic
generics were added to Go, without contracts. Generic functions may not use
methods or operators of their type parameters.

The answer is quite a lot, actually. The code would be verbose, but not
impossibly so.

-- 
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

[alanfo]

Well, whatever you may think of it, there's no doubt that a lot of the 
problems we currently have with generic constraints would go away if 
operator overloading were introduced into Go 2.

Personally, I wouldn't be dismayed if this were to happen. A lot of my 
stuff is mathematical in nature and this is an area where operator 
overloading works best - and indeed is expected - by programmers working in 
these disciplines.

However, I think it's important to learn the lessons of the past and not 
follow languages such as C++ or Scala where you can overload virtually 
anything or even make up your own operators which can result in confusing 
or even write-only code.

It is far better, in my view, just to permit the overloading of a limited 
subset of operators and for their signature, priority etc. to mirror those 
of the built-in ones.

In particular, I agree with Ian that there would be very little value in 
overloading the logical operators (&&, || and !) and that this should be 
disallowed.

I would also disallow overloading of the =, :=, <-, ..., [], {}, () and yes 
- equality operators - as well because I believe to do otherwise would be 
very confusing. 

The equality operators (== and !=) have a well defined meaning in Go 1 
which spans both built-in and user defined types and, to maintain backwards 
compatibility, I don't think this should be changed. When you want to use 
these operators purely for ordering purposes, they can always be reproduced 
by a combination of the other ordering operators as I said in another 
recent thread.

If you can't overload == and != then 'comparable' (or whatever you want to 
call it) would need to be a built-in interface.

Another possibility would be to introduce two new ordering operators, 
perhaps >< (for ==) and <> (for !=), which *could* be overloaded though the 
first of these would take some getting used to!

As for Eric's proposal - using an 'implements' keyword - I like it for the 
following reasons:

1. It avoids the need to make up a long list of names for the operators 
which folks either have to remember or look up in the spec.

2. It makes it easier to retrofit operator overloading to existing types 
for which suitable methods have already been defined.

3. As 'implements' would only be used in contexts which don't exist at 
present, it needn't be a 'full' keyword and would therefore be backwards 
compatible.

One area that hasn't been addressed so far is conversions. To convert to 
say, int64, I'd suggest 'implements int64()' and to convert from int64 
perhaps 'implements T(int64)' where T is the method's receiver type. TBH, I 
don't particularly like the idea of user-defined conversions at all but 
they're probably inevitable if you want to have unified generic constraints 
and at least they'd always be explicit.

Subject to all this, I think it might well be possible to get rid of 
contracts and just use interfaces for generic constraints.

Incidentally, I'm not a fan of wrapping types so that they can support the 
built-in operators. Although this is easy enough for scalar types, when you 
have slices, maps etc. of such types it's a different kettle of fish as 
wrapping/unwrapping requires a lot more code.

Alan

On Tuesday, October 16, 2018 at 3:24:50 AM UTC+1, Eric Raymond wrote:
>
> 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. 

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

[roger peppe]

I agree that rand.Shuffle could have used an interface type that's a
subset of sort.Interface. I'm not sure why it didn't, although of
course it's easy to go from one to the other:

func main() {
x := []int{1, 2, 3, 4, 5, 6, 7, 8, 9}
xi := sort.IntSlice(x)
rand.Shuffle(xi.Len(), xi.Swap)
fmt.Println(x)
}

As for passing the slice directly, I think it's better to keep APIs
type-safe, at least to start with.
If we find ourselves writing out the swap function many times, then we
could add a rand.ShuffleSlice function along the same lines as
sort.Slice:

func ShuffleSlice(x interface{}) {
rand.Shuffle(reflect.ValueOf(x).Len(), reflect.Swapper(x))
}

As others have pointed out, this is strictly less powerful than the
current rand.Shuffle. For example, you can't shuffle two slices at
once (not that uncommon if you're storing data column-oriented for
cache friendliness).
On Tue, 16 Oct 2018 at 05:29, Dan Kortschak
 wrote:
>
> ¡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.

-- 
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]

The attack does not require the attacker to have root on the compromised 
machine. It does, however, require the page file not to be encrypted, as is 
common on Linux and Unix systems. The attack I've described requires 
physical access, e.g. by quickly copying the hard disk. There are special 
tools and hardware for that. The attacker may need root access on his own 
system, not the root of the compromised system.

For example, the standard procedure of a law enforcement agency is to 
confiscate the machine, copy the hard drives, and then investigate the hard 
drives for forensic evidence, including e.g. checking the page files for 
master keys if necessary. Of course, your policy could be that a password 
manager ought not safeguard its users against law enforcement or similar 
dedicated attackers with physical access (but without tampering the 
original system, live monitoring with a debugger, etc.). But the reason why 
good password managers lock the memory is exactly to prevent these kind of 
attacks.

I'm not going into the politics about whether it's good to give ordinary 
people such strong encryption or not. I merely wanted to point out one 
weakness of the system. If you as an implementer "argue around" the issue, 
your potential future users will not necessarily consider this as a good 
sign. If I were you, I would simply lock the master key in memory to 
prevent it from being paged out instead.

On Monday, October 15, 2018 at 11:05:46 PM UTC+1, robert engels wrote:
>
> 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  
>> 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