Investigate supply chain security score (75/100) on Socket.dev

[leighmcculloch]

The go-stellar-sdk package currently has a supply chain security score of 75/100 on socket.dev: https://socket.dev/go/package/github.com/stellar/go-stellar-sdk.

As an SDK used by developers building on Stellar, and developers should be able to have confidence in the SDK's stability and suitability, we should understand what factors are contributing to this score and see if we can address them.

[leighmcculloch]

Okay, one reason according to the link above is because there are libs using os/exec. This one is particularly surprising, it's a client for communicating with stellar-core, but it shells out to docker run commands:

go-stellar-sdk/clients/stellarcore/client.go

Lines 92 to 126 in 3321201

	func GenSorobanConfigUpgradeTxAndKey(
	config GenSorobanConfig, upgradeConfig xdr.ConfigUpgradeSet) ([]xdr.TransactionEnvelope, xdr.ConfigUpgradeSetKey, error) {
	upgradeConfigB64, err := xdr.MarshalBase64(upgradeConfig)
	if err != nil {
	return nil, xdr.ConfigUpgradeSetKey{}, err
	}
	cmd := exec.Command("docker", "pull", config.StellarCoreImage)
	_, err = cmd.Output()
	if err != nil {
	return nil, xdr.ConfigUpgradeSetKey{}, err
	}
	cmd = exec.Command("docker",
	"run",
	"-i",
	config.StellarCoreImage,
	"get-settings-upgrade-txs",
	config.SigningKey.Address(),
	strconv.FormatUint(uint64(config.BaseSeqNum), 10),
	config.NetworkPassphrase,
	"--xdr", upgradeConfigB64,
	"--signtxs")
	inputStr := config.SigningKey.Seed()
	cmd.Stdin = strings.NewReader(inputStr)
	out, err := cmd.Output()
	if err != nil {
	return nil, xdr.ConfigUpgradeSetKey{}, err
	}
	lines := strings.Split(string(out), "\n")
	if len(lines) < 9 {
	return nil, xdr.ConfigUpgradeSetKey{}, fmt.Errorf("get-settings-upgrade-txs: unexpected output: %q", string(out))
	}
	txsB64 := []string{lines[0], lines[2], lines[4], lines[6]}
	keyB64 := lines[8]

[tamirms]

the functionality you highlighted is only used by integration tests in horizon. We could move that specific code to horizon. However, the captive core library still uses os/exec to invoke stellar-core and there is no way around that unfortunately