I would like to use signatures for a program that I am writing in Go, but I can't figure out the documentation, which is here. In particular, I would like to use the SignPKCS1v15 and VerifyPKCS1v15 functions, but I'm not sure exactly what I have to pass as arguments. I would greatly benefit from some example code of these two functions. Thanks.
Note: The message that I would like to send is a struct that I defined.
I think the src\pkg\crypto\rsa\pkcs1v15_test.go file in the Go source tree should be a good start.
An update striving provide more context… Go source contains many tests for the code in its standard library (and the crypto/rsa package is a part of it), so whenever you have no idea how to use a standard package (or, actually, any other Go package), a good place to start is to look at the tests involving that package as testing code naturally uses the package! Tests are kept in files ending in _test.go, usually have meaningful names and are located in the same directories actual code implementing a particular package is kept.
So in your particular case you could do this:
Download the Go source package of the version matching your compiler (what go version shows) and unpack it somewhere.
Navigate to the directory matching the package of interest. Code for standard Go packages is located in the "pkg" directory under the "src" top-level directory, so if you're interested in the crypto/rsa package, you need the src/pkg/crypto/rsa directory.
Related
Once a go program is compiled, is there any way one can extract the name of the packages (as later explained in the question) if the machine code is decompiled to Assembly (or then to C)?
In go we generally import packages by providing a link to the repo (if open source). For example github.com/abc/abc. This is means that the username of the library developer is usually part of the package import. Now, when the program is compiled, what happens to them? Can they be somehow extracted from the compiled binary?
Generally speaking, in think the compiler should put the whole code in one place and then it can get rid of those names, but I am unsure about it. That is why I asked the question. I asked this question because in one special case if that package import is somehow included in the binary, it will lead to a serious security problem.
After some investigation, I found that Go does include these in the binary. I opened the binary in a text editor and I tried to look up repo names. At the end of the file, there is a big text portion which includes a lot of textual information. The names of repos used in the program can also be simply looked up.
This means that if you are working on security projects where you need to hide as much information as possible, you need to somehow be careful about these.
I'm writing my first Go code which among other things, sends an email. After finding out that the package net/smtp only supports Plain Auth (but some providers like outlook doesn't support it), I asked for a solution and got pointed out to https://gist.github.com/andelf/5118732.
That code works like a charm, but as it's not something written by myself, I would like to add it in a separate file and just reference it in my main.go.
What's the right approach to have multiple files in the same package? I don't want to create a different package just for that code, first because it's not mine, and secondly, because I think it's an "overkill" approach, isn't it?
I thought that as long as the files are in the same directory, I could have many *.go files, but it seems it's not working out. If I just create a file with the content of that gist, the compiler fails because expected package, found import. If I add something like package auth, then it fails because found packages auth (auth.go) and main (main.go)
So, what's the general practice in this situations? Just create packages for everything?
You can have only one package in a directory, and it looks like you don't need a package for this addition, so you can simply put that in a separate file, and add package main at the top. Having a main package and putting everything under it works up to a point. As things get larger, you have to break it up into self-contained packages.
If your current working directory is in GOPATH, then you can just add new go file with same package name main.
If your current working directory is not in GOPATH, you can still put them in multiple go files and when you run the program, you should use go run *.go instead of just go run main.go.
There are also other options which you can refer Run code with multiple files in the same main package in GoLang for detail.
I wrote a function (not! main) and prompted go install. This command generated a path and a package in my pkg-directory. I tested the function by using it in a main function, generated the .exe and everything worked just fine.
After that, I wanted to see if I understood the concept of packages in go correctly and deleted the source file of the function in the src-directory and deleted the main .exe. I did not remove the package file in my pkg-directory. Then I tried to go install the main .exe again, but it didn't work: "package can not be found". I obviously missunderstood the whole concept because I thought I could use the packages in pkg without the source files in src. If my conclusion was correct, why do I need the "pkg" directory at all?
For more explanation take a look at this picture please:
In /bin is the binary code of the main function "hello". This main function also contains the function "reverse" of the "stringutil" package.
By generating the "hello.exe", Go also generates the package "stringutil" into pkg.
My question is: Should I not be able to delete "reverse.go" in src and still be able to use the same function because it was already put into pkg?
Is it just the way the AST works now that they've rewritten the compiler in go? It checks for GOPATH/src/**/.go when it parses the "imports", then when the linker goes to build the final binary, it'll go check pkg. So the compiler errors out first when trying to feed the ast to the assembler because of the incomplete source tree.
Thank you very much!!!
It is true that the pkg dir is usually used as a cache directory, but also It is possible to use packages without having the source code available, with a feature named binary only packages AFAIK It was implemented since Go 1.7.
However, there's a caveat for this approach: Versions of the compiler used to build the package and the compiler to 'use' the package to generate a new library/executable must match. Also, the files must match the pair of os/architecture to build against. If you want cross-compiling, you'll need to distribute your package to every pair of os/architecture you'll want to build.
This project has a demo for the aforementioned feature.
I hope my explanation was detailed enough :)
The pkg dir is just a local cache for compiling, it's not something you can depend upon and it doesn't replace .go files, it's not a static lib dir but a temp build products dir. It speeds up compilation, so you don't need the pkg dir, but compiles might be slower if it is empty, and it is for the compiler's use, not yours.
As you've discovered, you do need the src dir.
To link a static library to your project, you could copy out that .a file and use ldflags to link but then you lose all the nice things like cross-compiling and having the entire source for your app, so unlike c for example people don't typically do that.
I am building a web application in Go and as part of it I have several middelware functions defined. Right now they all live in "my/middleware" package. That namespace is becoming very cluttered by all the different functions I've defined so I decided to put them all in their own subdirectories, e.g. "my/middleware/gzip". When I do this I get the error:
no buildable Go source files my/middleware
I don't want all of these functions in the same namespace, but it seems my only option is to create a placeholder .go file in the my/middleware directory with an empty init function or something. That sounds terrible so I'd like suggestions on how to achieve my goal to group a similar class of packages when there isn't any shared/common code to live in the parent package.
You are actually taking the right decision by splitting the files into different subfolders. It is not different than what is done here
https://golang.org/pkg/compress/
This allows for the clients of your framework to take only what they need. The idea is to avoid dependency bloating. Go is all about being lean.
The error you receive is because you try to build a package that doesn't exist. Think of that folder as a logical grouping mechanism, you need to build the packages given by the child folders individually.
I'm developing a small tool with Go. And recently, I noticed that the tool needs to be invoked from a shell script, because it's using shell function.
Assume my tool is called atool. So, go build generates a binary atool, and my tool has a Go structure as github.com/myaccount/atool. Now, i want to build atool-cli binary with go build, and invoke it from shell script atool. How can I achieve this?
The only way coming in my mind is change go structure as github.com/myaccuont/atool-cli. But I don't want to do this because the already announced, and also, the path seems a bit funny name.
Just to make my comment "official":
go build -o atool-cli github.com/you/atool
One way packages structure themselves as a library, and provide main packages is to put their main entrypoints in subdirectories.
You can have a main package in github.com/myaccount/atool/atool-cli, which imports github.com/myaccount/atool and implements func main(). Some packages with multiple commands even have a /cmd/ directory with multiple cli tools that can be built (see camlistore as an example)