[go-nuts] Re: raw bit types without arithmetic

[Kevin Chowski]

Sorry, sent too early.

Obviously that doesn't support the bitwise type conversion you mentioned; I 
don't really have an opinion on that one, I don't really convert from float 
to bits very often.

It seems like the compiler optimizations you mention could happen with or 
without these extra types, if such optimizations just worked on byte arrays 
in general.

On Monday, May 13, 2024 at 9:38:36 PM UTC-6 Kevin Chowski wrote:

> How about just allowing bitwise operations on byte arrays (of the same 
> length)?
>
> On Monday, May 13, 2024 at 2:51:19 PM UTC-6 jimmy frasche wrote:
>
>> I'm not 100% sure if this is a good idea but it's been knocking around 
>> in my head all week so I thought I'd share in case it has any merit: 
>>
>> Introduce bitsN types for N=8, 16, 32, 64, 128, 256, and 512. 
>>
>> These are similar to uintN but they are unordered and have no 
>> arithmetic operations defined. 
>>
>> They only have literals, comparison, and bitwise operations. 
>> (fmt.Print and friends should render them in hex by default.) 
>>
>> Conversions between the numeric types and the bitN are allowed, which, 
>> for example, let's us rewrite math.Float64bits as simply 
>>
>> func Float64bits(f float64) uint64 { 
>> return uint64(bits64(f)) 
>> } 
>>
>> Since there are no arithmetic operations, the 128+ sizes should be 
>> fairly efficient to fake on architectures without special 
>> instructions/registers. 
>>
>> Potential uses: 
>>
>> UUIDs could be stored as a bits128 instead of a [2]uint64 or [16]byte. 
>>
>> SIMD vectors could be created and stored easily, even if they need 
>> assembly to operate on them efficiently. 
>>
>> Same for int128/uint128 values or even for more exotic numeric types 
>> like the various float16 definitions or "floating slash" rationals. 
>>
>> It would also be handy to have larger bitsets that are easy to work with. 
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1f0329c1-8b82-4683-999e-62b9a046c0a8n%40googlegroups.com.

[go-nuts] Re: raw bit types without arithmetic

[Kevin Chowski]

How about just allowing bitwise operations on byte arrays (of the same 
length)?

On Monday, May 13, 2024 at 2:51:19 PM UTC-6 jimmy frasche wrote:

> I'm not 100% sure if this is a good idea but it's been knocking around
> in my head all week so I thought I'd share in case it has any merit:
>
> Introduce bitsN types for N=8, 16, 32, 64, 128, 256, and 512.
>
> These are similar to uintN but they are unordered and have no
> arithmetic operations defined.
>
> They only have literals, comparison, and bitwise operations.
> (fmt.Print and friends should render them in hex by default.)
>
> Conversions between the numeric types and the bitN are allowed, which,
> for example, let's us rewrite math.Float64bits as simply
>
> func Float64bits(f float64) uint64 {
> return uint64(bits64(f))
> }
>
> Since there are no arithmetic operations, the 128+ sizes should be
> fairly efficient to fake on architectures without special
> instructions/registers.
>
> Potential uses:
>
> UUIDs could be stored as a bits128 instead of a [2]uint64 or [16]byte.
>
> SIMD vectors could be created and stored easily, even if they need
> assembly to operate on them efficiently.
>
> Same for int128/uint128 values or even for more exotic numeric types
> like the various float16 definitions or "floating slash" rationals.
>
> It would also be handy to have larger bitsets that are easy to work with.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d0507019-b796-47b6-a4e9-3e407879866cn%40googlegroups.com.

[go-nuts] raw bit types without arithmetic

[jimmy frasche]

I'm not 100% sure if this is a good idea but it's been knocking around
in my head all week so I thought I'd share in case it has any merit:

Introduce bitsN types for N=8, 16, 32, 64, 128, 256, and 512.

These are similar to uintN but they are unordered and have no
arithmetic operations defined.

They only have literals, comparison, and bitwise operations.
(fmt.Print and friends should render them in hex by default.)

Conversions between the numeric types and the bitN are allowed, which,
for example, let's us rewrite math.Float64bits as simply

func Float64bits(f float64) uint64 {
return uint64(bits64(f))
}

Since there are no arithmetic operations, the 128+ sizes should be
fairly efficient to fake on architectures without special
instructions/registers.

Potential uses:

UUIDs could be stored as a bits128 instead of a [2]uint64 or [16]byte.

SIMD vectors could be created and stored easily, even if they need
assembly to operate on them efficiently.

Same for int128/uint128 values or even for more exotic numeric types
like the various float16 definitions or "floating slash" rationals.

It would also be handy to have larger bitsets that are easy to work with.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANG3jX%2B_%3DhjfGEVAaOTToTRHsOVVqTmWQEZz9kzD-uYT0jNosA%40mail.gmail.com.

[go-nuts] Re: programmatic way to find if application go binary is built with -cover flag ?

[Tamás Gulácsi]

runtime/debug.ReadBuildInfo is a good source of truth:
$ strings bin/godeb|grep '^build\s'

build   -buildmode=exe
build   -compiler=gc
build   
DefaultGODEBUG=httplaxcontentlength=1,httpmuxgo121=1,panicnil=1,tls10server=1,tlsrsakex=1,tlsunsafeekm=1
build   CGO_ENABLED=1
build   CGO_CFLAGS=
build   CGO_CPPFLAGS=
build   CGO_CXXFLAGS=
build   CGO_LDFLAGS=
build   GOARCH=amd64
build   GOOS=linux
build   GOAMD64=v1
build   -buildmode=exe
build   -compiler=gc
build   
DefaultGODEBUG=httplaxcontentlength=1,httpmuxgo121=1,panicnil=1,tls10server=1,tlsrsakex=1,tlsunsafeekm=1
build   CGO_ENABLED=1
build   CGO_CFLAGS=
build   CGO_CPPFLAGS=
build   CGO_CXXFLAGS=
build   CGO_LDFLAGS=
build   GOARCH=amd64
build   GOOS=linux
build   GOAMD64=v1

Akash Kumar a következőt írta (2024. május 13., hétfő, 18:42:30 UTC+2):

> I am writing an external go program that will take the path to another go 
> binary as argument, and checks if the binary was built with cover flag.
>
> `debug.ReadBuildInfo()` is meant for getting build info embedded in the 
> running binary as 
> > ReadBuildInfo returns the build information embedded in the running 
> binary 
>
> On Monday, May 13, 2024 at 6:37:46 PM UTC+5:30 Zxilly Chou wrote:
>
>> try debug.ReadBuildInfo(), then iterate the pair in the buildinfo.
>> Settings
>>
>> 在2024年5月13日星期一 UTC+8 20:56:51 写道：
>>
>>> Is there a way in go to find whether a go binary is built with -cover 
>>> flag ?
>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/aa819a76-2c8e-4b9a-b37d-92abd3ff2877n%40googlegroups.com.

Re: [go-nuts] Re: VCS Stamping - How To Use It? How to debug failures?

[Adam Kaplan]

I forgot to add one more detail - the go-toolset image defaults to running
as user "default" (UID 1001).

Adding `USER root` right after the `FROM` declaration is another way to
work around the issue I described, but from a security perspective I would
advise against it.

On Mon, May 13, 2024 at 12:24 PM Adam Kaplan  wrote:

> Great suggestion Jason - adding `git status` took me in a very unexpected
> direction, and ultimately a solution.
>
> tl;dr if your build's base container image does not use root/uid 0, git
> commands won't work unless you add the `--chown=` flag to your `COPY`
> instruction. Go builds need this if you want `-buildvcs=auto|true` to
> succeed.
>
> When I changed my build command to `RUN git status && go build` in the
> Dockerfile, I got the following output:
>
> ```
> $ podman build -t localhost/sclorg/hello-openshift:latest .
> [1/2] STEP 1/3: FROM registry.redhat.io/ubi9/go-toolset:1.20.12 AS builder
> [1/2] STEP 2/3: COPY . .
> --> 10a13b463199
> [1/2] STEP 3/3: RUN git status && go build -o /tmp/hello
> fatal: detected dubious ownership in repository at '/opt/app-root/src'
> To add an exception for this directory, call:
>
> git config --global --add safe.directory /opt/app-root/src
> Error: building at STEP "RUN git status && go build -o /tmp/hello": while
> running runtime: exit status 128
> ```
>
> This was a new and different error message for me - but same exit code as
> before. A quick Google search brought me to CVE-2022-24765 [1], whose fix
> introduced this "dubious ownership" message/protection.
>
> I was finally able to piece everything together with a few more debug
> builds and internet searches:
>
> 1. On Fedora 39, podman runs in "rootless" mode. Files owned by me show up
> as owned by "root" in containers.
> 2. For Linux containers, `COPY` commands in Dockerfiles copy files as
> UID/GID 0 unless the `--chown` flag is passed. [2].
> 3. As part of the mitigation for CVE-2022-24765, git commands will succeed
> only if:
>   a. The `.git` directory is owned by the same user executing the `.git`
> command OR
>   b. The parent directory marked "safe" in the git configuration.
>
> Using `COPY --chown=default . .` instead of `COPY . .` works for the UBI
> go-toolset image referenced previously in this thread. Your results may
> vary using other golang "builder" images.
>
> [1] https://github.blog/2022-04-12-git-security-vulnerability-announced/
> [2] https://docs.docker.com/reference/dockerfile/#copy---chown---chmod
>
>
> On Sat, May 11, 2024 at 11:43 AM Jason E. Aten  wrote:
>
>> > how can developers debug and find the root cause?
>>
>> If it was me, I would start by going into the container (whatever the
>> podman equivalent of docker exec -it containernumber bash) and try to run
>> 'git status' or 'git log' and see why the git query is giving an error.
>> You could also try strace to see what git command specifically is being
>> execed, then try to get that command working manually.
>>
>> --
>> 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/LZbM2WlZoJM/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/ca680397-1497-4b3a-83ce-301c936308c1n%40googlegroups.com
>> 
>> .
>>
>
>
> --
>
> Adam Kaplan
>
> He/Him
>
> Principal Software Engineer
>
> Red Hat 
>
> 100 E. Davie Street
>
> adam.kap...@redhat.comT: 1-919-754-4843
> 
>
>

-- 

Adam Kaplan

He/Him

Principal Software Engineer

Red Hat 

100 E. Davie Street

adam.kap...@redhat.comT: 1-919-754-4843


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CADmLb%2Bkfvd%3DYbnzW1QzgkTe93UUkOfW9TtCBf168DEi8YxWJ1w%40mail.gmail.com.

Re: [go-nuts] Re: VCS Stamping - How To Use It? How to debug failures?

[Adam Kaplan]

Great suggestion Jason - adding `git status` took me in a very unexpected
direction, and ultimately a solution.

tl;dr if your build's base container image does not use root/uid 0, git
commands won't work unless you add the `--chown=` flag to your `COPY`
instruction. Go builds need this if you want `-buildvcs=auto|true` to
succeed.

When I changed my build command to `RUN git status && go build` in the
Dockerfile, I got the following output:

```
$ podman build -t localhost/sclorg/hello-openshift:latest .
[1/2] STEP 1/3: FROM registry.redhat.io/ubi9/go-toolset:1.20.12 AS builder
[1/2] STEP 2/3: COPY . .
--> 10a13b463199
[1/2] STEP 3/3: RUN git status && go build -o /tmp/hello
fatal: detected dubious ownership in repository at '/opt/app-root/src'
To add an exception for this directory, call:

git config --global --add safe.directory /opt/app-root/src
Error: building at STEP "RUN git status && go build -o /tmp/hello": while
running runtime: exit status 128
```

This was a new and different error message for me - but same exit code as
before. A quick Google search brought me to CVE-2022-24765 [1], whose fix
introduced this "dubious ownership" message/protection.

I was finally able to piece everything together with a few more debug
builds and internet searches:

1. On Fedora 39, podman runs in "rootless" mode. Files owned by me show up
as owned by "root" in containers.
2. For Linux containers, `COPY` commands in Dockerfiles copy files as
UID/GID 0 unless the `--chown` flag is passed. [2].
3. As part of the mitigation for CVE-2022-24765, git commands will succeed
only if:
  a. The `.git` directory is owned by the same user executing the `.git`
command OR
  b. The parent directory marked "safe" in the git configuration.

Using `COPY --chown=default . .` instead of `COPY . .` works for the UBI
go-toolset image referenced previously in this thread. Your results may
vary using other golang "builder" images.

[1] https://github.blog/2022-04-12-git-security-vulnerability-announced/
[2] https://docs.docker.com/reference/dockerfile/#copy---chown---chmod


On Sat, May 11, 2024 at 11:43 AM Jason E. Aten  wrote:

> > how can developers debug and find the root cause?
>
> If it was me, I would start by going into the container (whatever the
> podman equivalent of docker exec -it containernumber bash) and try to run
> 'git status' or 'git log' and see why the git query is giving an error.
> You could also try strace to see what git command specifically is being
> execed, then try to get that command working manually.
>
> --
> 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/LZbM2WlZoJM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/ca680397-1497-4b3a-83ce-301c936308c1n%40googlegroups.com
> 
> .
>


-- 

Adam Kaplan

He/Him

Principal Software Engineer

Red Hat 

100 E. Davie Street

adam.kap...@redhat.comT: 1-919-754-4843


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CADmLb%2B%3DpPMFT5fnBpC4C8QuxD%3DFNTO1c74o6Nx6F6zL2eJALbg%40mail.gmail.com.

[go-nuts] Re: programmatic way to find if application go binary is built with -cover flag ?

[Akash Kumar]

I am writing an external go program that will take the path to another go 
binary as argument, and checks if the binary was built with cover flag.

`debug.ReadBuildInfo()` is meant for getting build info embedded in the 
running binary as 
> ReadBuildInfo returns the build information embedded in the running 
binary 

On Monday, May 13, 2024 at 6:37:46 PM UTC+5:30 Zxilly Chou wrote:

> try debug.ReadBuildInfo(), then iterate the pair in the buildinfo.Settings
>
> 在2024年5月13日星期一 UTC+8 20:56:51 写道：
>
>> Is there a way in go to find whether a go binary is built with -cover 
>> flag ?
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/81a62099-4b33-4048-80a6-15b3332767d1n%40googlegroups.com.

[go-nuts] Re: programmatic way to find if application go binary is built with -cover flag ?

[Zxilly Chou]

try debug.ReadBuildInfo(), then iterate the pair in the buildinfo.Settings

在2024年5月13日星期一 UTC+8 20:56:51 写道：

> Is there a way in go to find whether a go binary is built with -cover flag 
> ?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b78a192f-80f9-4a93-a1d6-bed613e56000n%40googlegroups.com.

[go-nuts] programmatic way to find if application go binary is built with -cover flag ?

[Akash Kumar]

Is there a way in go to find whether a go binary is built with -cover flag ?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e0a2d60f-9f86-48b9-a265-316a575a6427n%40googlegroups.com.

[go-nuts] Re: question about src/cmd/go/internal/script/cmds_posix.go and windows

[peterGo]

Hiroaki,

go/src/cmd/go/internal/test/test_nonunix.go

//go:build !unix

package test

func isETXTBSY(err error) bool {
// syscall.ETXTBSY is only meaningful on Unix platforms.
return false
}

peter

On Monday, May 13, 2024 at 4:32:38 AM UTC-4 hnak...@gmail.com wrote:

> Hi,
> I found that
>
> https://github.com/golang/go/blob/07fc59199b9522bfe0d14f35c4391394efc336c9/src/cmd/go/internal/script/cmds_posix.go
> has the build tag
> //go:build unix || windows
>
> Is windows really needed here? (I suppose not)
>
> isETXTBSY is also defined in
>
> https://github.com/golang/go/blob/07fc59199b9522bfe0d14f35c4391394efc336c9/src/cmd/go/internal/test/test_unix.go
> and its build tag is:
> //go:build unix
> which I think correct.
>
> Thanks,
> Hiroaki
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b3a5600f-b748-436e-8d81-9682d4c7bc0an%40googlegroups.com.

[go-nuts] Re: question about src/cmd/go/internal/script/cmds_posix.go and windows

[peterGo]

Hiroaki,

go/src/syscall/zerrors_windows.go

// Invented values to support what package os and others expects.
const (
...
ETXTBSY
...
)

peter
On Monday, May 13, 2024 at 4:32:38 AM UTC-4 hnak...@gmail.com wrote:

> Hi,
> I found that
>
> https://github.com/golang/go/blob/07fc59199b9522bfe0d14f35c4391394efc336c9/src/cmd/go/internal/script/cmds_posix.go
> has the build tag
> //go:build unix || windows
>
> Is windows really needed here? (I suppose not)
>
> isETXTBSY is also defined in
>
> https://github.com/golang/go/blob/07fc59199b9522bfe0d14f35c4391394efc336c9/src/cmd/go/internal/test/test_unix.go
> and its build tag is:
> //go:build unix
> which I think correct.
>
> Thanks,
> Hiroaki
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/de181ed7-e9c8-4683-8f1d-8b9cabe665cdn%40googlegroups.com.

[go-nuts] question about src/cmd/go/internal/script/cmds_posix.go and windows

[hnak...@gmail.com]

Hi,
I found that
https://github.com/golang/go/blob/07fc59199b9522bfe0d14f35c4391394efc336c9/src/cmd/go/internal/script/cmds_posix.go
has the build tag
//go:build unix || windows

Is windows really needed here? (I suppose not)

isETXTBSY is also defined in
https://github.com/golang/go/blob/07fc59199b9522bfe0d14f35c4391394efc336c9/src/cmd/go/internal/test/test_unix.go
and its build tag is:
//go:build unix
which I think correct.

Thanks,
Hiroaki

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8de9aed7-a2ad-4e94-a8ce-ec405b8e0da9n%40googlegroups.com.