[go-nuts] Extracting Syncthing TLS secrets
Hi, I'm not sure if this is really a Wireshark, Go, or Syncthing question; I tried the Wireshark dev list [0] but got no response, so I figured I'll try here: I'm working on a Wireshark Syncthing dissector [1]. Since most of the Syncthing protocols are encapsulated in TLS, I need to provide the TLS secrets to Wireshark. I read this: https://wiki.wireshark.org/TLS Syncthing is written in Go, so I patched it to export TLS secrets: https://github.com/tmo1/syncthing/blob/f770faca1bee4d5b12346c5ac78cd4f6ac3a6012/lib/syncthing/syncthing.go#L273 This works, and various stuff is written to the specified file, but providing that file to Wireshark doesn't enable TLS decryption. I examined the file, and I see that it contains CLIENT_HANDSHAKE_TRAFFIC_SECRET, SERVER_HANDSHAKE_TRAFFIC_SECRET, CLIENT_TRAFFIC_SECRET_0, and SERVER_TRAFFIC_SECRET_0 lines, but not the critical CLIENT_RANDOM lines. Am I doing something wrong or missing something? [0] https://www.wireshark.org/lists/wireshark-dev/202206/msg5.html [1] https://github.com/tmo1/wireshark-syncthing-dissector -- Tmore1 -- 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/20220617173717.a589a8f16693d15f4019fcc2%40gmx.com.
[go-nuts] Issue syscall.Proc.Call win32 function ERROR_MORE_DATA
Hello,
I am trying to use cfapi.h/cldapi.dll from golang.
I am able to call some function however for CfConnectSyncRoot I always get
ERROR_MORE_DATA on the third argument of syscall.Proc.Call().
Cf my code:
func CfConnectSyncRoot(syncRootPath string, callbackTable
CfCallbackRegistrations, callbackContext []byte, connectFlags
CfConnectFlag) (*CfConnectionKey, error) {
wstrSyncRootPath, err := syscall.UTF16PtrFromString(syncRootPath)
if err != nil {
return nil, err
}
ct := callbackTable.DllEncode()
cbCtx := uintptr(0)
if len(callbackContext) > 0 {
cbCtx = uintptr(unsafe.Pointer(&callbackContext[0]))
}
cfKey := CfConnectionKey(0)
ret, _, errno :=
inst.hCfConnectSyncRoot.Call(uintptr(unsafe.Pointer(wstrSyncRootPath)),
uintptr(unsafe.Pointer(&ct[0])), cbCtx, uintptr(connectFlags), uintptr
(unsafe.Pointer(&cfKey)))
fmt.Println(errno)
if ret != S_OK {
return nil, fmt.Errorf("Error CfConnectSyncRoot result %#x", ret)
}
return &cfKey, nil
}
fmt.Println(errno) is throwing the error code.
Do you have any idea ?
Thanks in advance,
Nicolas
--
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/a9948362-06d4-4581-b04f-c5940cd038edn%40googlegroups.com.
Re: [go-nuts] How to return concrete implementation to satisfy interface
This is called "covariance" and the FAQ attempts to answer this question:
https://go.dev/doc/faq#covariant_types
Personally, I'm not fully convinced Go shouldn't have co/contravariant
`func`, but I feel this has been ingrained for over ten years now and it's
unlikely to change.
On Fri, Jun 17, 2022 at 9:11 PM Deividas Petraitis
wrote:
> Today while working on my side project I have encountered interesting
> issue and despite I was able to overcome it I have realised that I might be
> missing some import concepts about Go.
> Let me share example code to demostrate the issue I am referring to:
>
> ```go
> package main
>
> import (
> "net/http"
>
> "github.com/gorilla/mux"
> )
>
> func main() {
> // We can pass GorillaRouter as Router, because it implement required
> methods
> _ = ServerHandler{
> router: NewGorillaRouter(),
> }
>
> // We can not pass FailingRouter as Router, because of:
> // cannot use FailingRouter{} (value of type FailingRouter) as type
> Router in struct literal:
> // FailingRouter does not implement Router (wrong type for HandleFunc
> method)
> //have HandleFunc(path string, handler func(http.ResponseWriter,
> *http.Request)) *FailingRoute
> //want HandleFunc(path string, handler func(http.ResponseWriter,
> *http.Request)) Route
> _ = ServerHandler{
> router: FailingRouter{},
> }
> }
>
> type ServerHandler struct {
> router Router
> }
>
> type Router interface {
> HandleFunc(path string, handler func(http.ResponseWriter,
> *http.Request)) Route
> }
>
> type Route interface {
> Methods(methods ...string) Route
> }
>
> func NewGorillaRouter() *GorillaRouter {
> return &GorillaRouter{
> router: mux.NewRouter(),
> }
> }
>
> type GorillaRouter struct {
> router *mux.Router
> }
>
> func (gr *GorillaRouter) HandleFunc(path string, handler
> func(http.ResponseWriter, *http.Request)) Route {
> return &GorillaRoute{
> route: gr.router.HandleFunc(path, handler),
> }
> }
>
> type GorillaRoute struct {
> route *mux.Route
> }
>
> func (r *GorillaRoute) Methods(methods ...string) Route {
> r.route = r.route.Methods(methods...)
> return r
> }
>
> type FailingRouter struct{}
>
> func (fr *FailingRouter) HandleFunc(path string, handler
> func(http.ResponseWriter, *http.Request)) *FailingRoute {
> return &FailingRoute{}
> }
>
> type FailingRoute struct{}
>
> func (r *FailingRoute) Methods(methods ...string) *FailingRoute {
> return r
> }
> ```
>
> For convienence you can find soure code from above and run it here:
> https://go.dev/play/p/M6N48FeegND
> Now when code and context is clear question is following: why in
> `FailingRouter` assignment compiler is not happy while in `GorillaRouter`
> it is happy?
>
> Or to rephrase, why assigning concrete implementation to a parameter of
> interface type is accepted:
>
> ```go
> type ServerHandler struct {
> router Router // assigning GorillaRouter to router is accepted
> }
> ```
>
> but vice versa is not and throws an error:
>
> ```go
> HandleFunc(path string, handler func(http.ResponseWriter, *http.Request))
> *FailingRoute // returning concrete that implements Router is not allowed
> ```
> Is my approach ( `GorillaRouter` ) correct solution for this problem?
>
> P.S. Sorry about the title, I am still not sure is it right for this
> problem description.
>
> --
> 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/fdc03ca3-f899-455a-8b7c-319c646f483an%40googlegroups.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFQ8%3D1TK5xXr1M573dj%2B3%2Bhujr%2BizBo3U%3Dr2K9J0PLD4A%40mail.gmail.com.
[go-nuts] How to return concrete implementation to satisfy interface
Today while working on my side project I have encountered interesting issue
and despite I was able to overcome it I have realised that I might be
missing some import concepts about Go.
Let me share example code to demostrate the issue I am referring to:
```go
package main
import (
"net/http"
"github.com/gorilla/mux"
)
func main() {
// We can pass GorillaRouter as Router, because it implement required
methods
_ = ServerHandler{
router: NewGorillaRouter(),
}
// We can not pass FailingRouter as Router, because of:
// cannot use FailingRouter{} (value of type FailingRouter) as type
Router in struct literal:
// FailingRouter does not implement Router (wrong type for HandleFunc
method)
//have HandleFunc(path string, handler func(http.ResponseWriter,
*http.Request)) *FailingRoute
//want HandleFunc(path string, handler func(http.ResponseWriter,
*http.Request)) Route
_ = ServerHandler{
router: FailingRouter{},
}
}
type ServerHandler struct {
router Router
}
type Router interface {
HandleFunc(path string, handler func(http.ResponseWriter,
*http.Request)) Route
}
type Route interface {
Methods(methods ...string) Route
}
func NewGorillaRouter() *GorillaRouter {
return &GorillaRouter{
router: mux.NewRouter(),
}
}
type GorillaRouter struct {
router *mux.Router
}
func (gr *GorillaRouter) HandleFunc(path string, handler
func(http.ResponseWriter, *http.Request)) Route {
return &GorillaRoute{
route: gr.router.HandleFunc(path, handler),
}
}
type GorillaRoute struct {
route *mux.Route
}
func (r *GorillaRoute) Methods(methods ...string) Route {
r.route = r.route.Methods(methods...)
return r
}
type FailingRouter struct{}
func (fr *FailingRouter) HandleFunc(path string, handler
func(http.ResponseWriter, *http.Request)) *FailingRoute {
return &FailingRoute{}
}
type FailingRoute struct{}
func (r *FailingRoute) Methods(methods ...string) *FailingRoute {
return r
}
```
For convienence you can find soure code from above and run it here:
https://go.dev/play/p/M6N48FeegND
Now when code and context is clear question is following: why in
`FailingRouter` assignment compiler is not happy while in `GorillaRouter`
it is happy?
Or to rephrase, why assigning concrete implementation to a parameter of
interface type is accepted:
```go
type ServerHandler struct {
router Router // assigning GorillaRouter to router is accepted
}
```
but vice versa is not and throws an error:
```go
HandleFunc(path string, handler func(http.ResponseWriter, *http.Request))
*FailingRoute // returning concrete that implements Router is not allowed
```
Is my approach ( `GorillaRouter` ) correct solution for this problem?
P.S. Sorry about the title, I am still not sure is it right for this
problem description.
--
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/fdc03ca3-f899-455a-8b7c-319c646f483an%40googlegroups.com.
