DEV Community: Christophe Colombier

Follow up: I'm back to dev.to

Christophe Colombier — Tue, 10 Sep 2024 12:24:46 +0000

After long pause, because of my newborn daugther, I'm back to dev.to

I'm a dad again 🤩🥳 dev.to pause

Christophe Colombier ・ Apr 26

#community

I will try to post things again.

Today, I posted a series about Integer overflow in Go

About the gosec G115 drama, or how I faced back integer conversion overflow in Go 🤯

Christophe Colombier ・ Sep 9

#go #programming #security

go-safecast: Safe number conversion in Go 🪄

Christophe Colombier — Tue, 10 Sep 2024 11:45:00 +0000

I worked on my first open-source package last weekend.

ccoVeille / go-safecast

Safe number conversion in Go: address gosec G115 and cwe-190 Integer Overflow or Wraparound

🪄 go-safecast: safe numbers conversion

go-safecast solves the type conversion issues in Go

In Go, integer type conversion can lead to a silent and unexpected behavior and errors if not handled carefully.

This package helps to convert any number to another, and report an error when if there would be a loss or overflow in the conversion

Usage

package main
import (
  "fmt"
  "math"

  "github.com/ccoveille/go-safecast"
)

func main() {
  var a int

  a = 42
  b, err := safecast.ToUint8(a) // everything is fine
  if err != nil {
    fmt.Println(err)
  }
  fmt.Println(b)
  // Output: 42

  a = 255 + 1
  _, err = safecast.ToUint8(a) // 256 is greater than uint8 maximum value
  if err != nil {
    fmt.Println(err)
    // Output: conversion issue: 256

…

View on GitHub

About the story behind this library, you can read my first article about integer overflow in Go

About the gosec G115 drama, or how I faced back integer conversion overflow in Go 🤯

Christophe Colombier ・ Sep 9 '24

#go #programming #security

As I found nothing to cope with this kind of error, except adding a lot of boilerplate for each cast to do, so I decided to make my own Go package.

@ldemailly helped me to review the code, thank.

The package is now mature enough for me to talk about it.

So instead of this


var a int
var b uint8

a = 255 + 1
b = uint8(a)
if a < 0 || a > math.MaxUint8 {
    log.Println("overflow")
}
fmt.Println(b)

a = -1
b = uint8(a)
if a < 0 || a > math.MaxUint8 {
    log.Println("overflow")
}
fmt.Println(b)

c, d := 255, 300
res := max(c, d)
if res < 0 || res > math.MaxInt8 {
    log.Println("overflow")
}
fmt.Println(int8(res))

str := "\x99" // hexadecimal representation of Trademark ASCII character: ™
e := str[0]
if e < 0 || e > math.MaxInt8 {
    log.Println("overflow")
}
fmt.Println(int8(e))

Go Playground

You can now do this

var a int
var b uint8

a = 255 + 1
b, err := safecast.ToUint8(a)
if err != nil {
    log.Println(err)
}
fmt.Println(b)

a = -1
b, err = safecast.ToUint8(a)
if err != nil {
    log.Println(err)
}
fmt.Println(b)

c, d := 255, 300
res := max(c, d)
g, err := safecast.ToInt8(res)
if err != nil {
    log.Println(err)
}
fmt.Println(g)

str := "\x99" // hexadecimal representation of Trademark ASCII character: ™
e := str[0]
f, err := safecast.ToUint8(e)
if err != nil {
    log.Println(err)
}
fmt.Println(f)

Go Playground

I'm curious about your feedbacks

Go: integer overflows

Christophe Colombier — Tue, 10 Sep 2024 09:00:03 +0000

Let's continue my articles about integer overflows in Go.

Here are examples

var a int
var b uint8

a = 255 + 1
b = uint8(a)
fmt.Println(b) // 0 conversion overflow

a = -1
b = uint8(a)
fmt.Println(b) // 255 conversion overflow

c, d := 255, 300
res := int8(max(c, d))
fmt.Println(res) // 44

str := "\x99"             // hexadecimal representation of Trademark ASCII character: ™
fmt.Println(str[0])       // 153
fmt.Println(int8(str[0])) // -103

Go Playground

About the gosec G115 drama, or how I faced back integer conversion overflow in Go 🤯

Christophe Colombier — Mon, 09 Sep 2024 22:10:48 +0000

Go is a strongly typed language, it avoids making mistakes.

I wrongly assumed Go was handling integer overflows, and reported an error.

Here is the perfect world where everything works as expected

a := int64(42)
b := uint8(a)
fmt.Println(b) // 42

So what does the following code

a = 255 + 1    // 255 is the higher value an uint8 can reach
b = uint8(a)
fmt.Println(b) // ?

a = -1
b = uint8(a)
fmt.Println(b) // ?

Here is the solution

Spoiler: it doesn't work as expected, or at least as we could expect.

So here Go is doing a silent conversion, of course it cannot store the value in the integer types provided, but there is no panic at all.

There are consequences: CWE-190. Please note CWE-190 is Common Weakness that affects a lot of language, and that is documented since 2006-07-19.

Imagine you access a resource by its identifier, but you need to convert from an integer type to another, you may allow to access to another resource.

Because of this, gosec a linter focused on improving the security in Go, provided a linter to detect the issue: the linter G115

The G115 linter idea was good.

But it was unfortunately merged with some false issues, that are now addressed, except a few ones.

The problem becomes massive after gosec v2.21.0 was merged into golangci-lint 1.60.2

Many people disabled gosec G115, because of the false positives and noise it was bringing to the CI. They were so numerous false-positives, they couldn't be fixed with a //nolint:gosec // disable G115 directive.

The problem is now (almost) fixed with golangci-lint 1.61.0 (that ships gosec v2.21.2, there are still a few remaining false-positive issues that need to be addressed, but they are less frequent.

Unfortunately, during that 2 weeks delay, many people chose to disable the G115 checker, you can see it easily on GitHub

Maybe, they would enable them back now.

git switch and git restore, or why not using git checkout

Christophe Colombier — Sat, 04 May 2024 14:58:56 +0000

git checkout command exists since the beginning of git

It is used for these things:

creating new branch

git checkout -b new-feature upstream/main

switching branch

git checkout main

restoring unstaged changes

git checkout README.md

checking out code from other branch

git checkout v1.0.0 -- README.md

git checkout command confuses everyone who start using git

Why?

Because it mixes two concepts:

branches juggling
restoring files

That's why new commands were added with Git 2.23 (August 2019, almost 5 years ago):

git switch: for playing with branches
git restore: for restoring files.

git restore can be used as a simple replacement on action on files.

the only noticeable changes between git switch and git checkout is that branch creation was done with git checkout -b name while it's now git switch -c name

Credit: https://twitter.com/_risacan_/status/1162539626373865472

Git commit helper: add emojis to your commits

Christophe Colombier — Sat, 04 May 2024 06:49:39 +0000

Following the article wrote by @muzammil-cyber

Git Commit Message Decoder: New Coder Edition

Muhammad Muzammil Loya ・ May 3

#git #programming #productivity

I would recommend anyone looking for having emojis in their commits to use the following tool made by @carloscuesta

carloscuesta / gitmoji-cli

A gitmoji interactive cli tool for using emojis on commits. 💻

gitmoji-cli

A gitmoji interactive client for using gitmojis on commit messages.

About

This project provides an easy solution for using gitmoji from your command line. Gitmoji-cli solves the hassle of searching through the gitmoji list. Includes a bunch of options you can play with! 🎉

Install

npm

npm i -g gitmoji-cli

brew

brew install gitmoji

Usage

gitmoji --help

A gitmoji interactive client for using gitmojis on commit messages.

  Usage
    $ gitmoji
  Options
    --init, -i      Initialize gitmoji as a commit hook
    --remove, -r    Remove a previously initialized commit hook
    --config, -g    Setup gitmoji-cli preferences.
    --commit, -c    Interactively commit using the prompts
    --list, -l      List all the available gitmojis
    --search, -s    Search gitmojis
    --version, -v   Print gitmoji-cli installed version
    --update, -u    Sync emoji list with the repo

Commit

You can use the commit functionality in two ways, directly or via a commit-hook.

If you want to integrate gitmoji-cli in your project I…

View on GitHub

You can select the right emoji for your commits.

You can also use @folke devmoji

folke / devmoji

🤖 🚀 ✨ Emojify your conventional commits with Devmoji

✨ Devmoji

Using Conventional Commits ⭐ as a standard for your commit messages, makes Semantic Versioning 🔖 as easy as can be, with tools like Conventional Changelog 📄 Standard Version 🔖 and Semantic Release 📦🚀

Devmoji is a command line tool that adds color 🌈 to conventional commits, using emojis inspired by Gitmoji 😜

Some of the things Devmoji can do:

emojify: convert input between diferent emoji formats unicode, shortcode and devmoji. devmoji are easy to remember aliases like: :test:, :refactor:, :docs:, :security instead of hard to remember emoji codes
git commit: install a prepare-commit-msg commit hook to ✨ automagically emojify and lints your commit message
git log: emojify and colorify the output of git log even for projects not using emojis

What does it look like?

see the commit messages of the Devmoji github repository
generated Devmoji CHANGELOG.md

📦 Installation

Install with npm…

View on GitHub

This one transform your commit message into emoji.

Both can allow you to enforce conventional commits

Build your own Octocat avatar, and share your creations on dev.to

Christophe Colombier — Fri, 03 May 2024 16:16:21 +0000

I just wrote an introduction about GitHub's Octocat

The story behind GitHub logo

Christophe Colombier ・ May 3

#github #community #watercooler #programming

I made this post because I wanted to brind some fun on dev.to by suggesting something.

Today, I found back https://myoctocat.com/ a site made to create you own Octocat avatar

I would like everyone to share their creations.

The story behind GitHub logo

Christophe Colombier — Fri, 03 May 2024 16:12:29 +0000

Everyone (at least among developers) knows the GitHub's logo.

Several knows the mascot is named Octocat, it's a merge between octopuss and cat

Some knows the story behind this logo creation.

The idea for GitHub’s logo came from its “octopus merge” – the practice of combining three or more branches of development. Initially the logo’s designer Simon Oxley thought about calling his creation ‘Octopuss’ (combination of octopus and pussycat) to represent how complex code combines can create peculiar things. But in the end, GitHub decided to go with ‘Octocat’ (for obvious reasons).

The logo was created by Simon Oxley, who doesn't remember creating it, apparently.

Original GitHub Octocat designer Simon Oxley

Original GitHub Octocat designer Simon Oxley on his famous creation: "I don't remember drawing it" Simon Oxley is the sort of fellow who makes dry jokes so subtle that Americans will miss them. He's not a developer, techie, or household name in Silicon Valley.

linkedin.com

More information is available on Wikipedia's page of GitHub

2024-05-03 my weekly dev.to recommendation

Christophe Colombier — Fri, 03 May 2024 16:00:00 +0000

Many articles but also topics in my weekly dev.to recommendations.

These are the articles I liked and recommend you reading

you are your own maintainer

It Took Me 20+ Years To Learn This Lesson About Dev

Matt Butcher for Fermyon ・ May 1

#beginners #programming #productivity #career

I would sum up like this: your today's code is your future legacy code.

Thanks @technosophos for sharing your thoughts on dev and work

Here are the articles I wrote about same topics (click to unfold)

How to be a better developer for you and the others

Christophe Colombier ・ Apr 7

#programming #devjournal #howto #workplace

Discover your cognitive biases 🧠🤔, and how to deal with them 💪🤩 !

Christophe Colombier ・ Apr 22

#psychology #workplace

why and when automating things

Why Automate?

Adam Ross ・ Apr 30

#software #automation #productivity #tooling

Thanks @grayside, I can see your passion to XKCD

a good article about password management

Password Management: The Basics

Gearoid O'Treasaigh ・ May 2

#password #habits #security

Thanks @gearoidotreasaigh

An interesting and detailed article about code review.

I approve and second author's guidelines and ideas:

Mastering Code Review: A Guide for Reviewers and PR Creators

Tássio ・ Apr 27

#productivity #career #learning

Thanks @tassiofront

The story behind gzip

The Magical Algorithms Written by Two Old Men, Dominating the World

huizhou92 ・ Apr 26

#computerscience #computerhistory #algorithms

Thanks @huizhou92

why you need a rubber duck

The amazing rubber duck techniques I use for years now, explained and discussed in this post

Are you Into Rubber Duck Debugging?

Anita Olsen*°•.¸☆ ・ Apr 23

#discuss #programming #coding

Thanks @anitaolsen

an interesting alternative to classic Readme profile on GitHub

GitHub: Create your own repository landscape ⭐️

Tung Leo ・ Apr 28

#github #opensource #githubactions #tooling

Thanks @tungbq

a good article article about email protection behind tools, but also privacy

Protect your emails (Short note)

Alex P ・ May 1

#email #pgp #privacy #security

Thanks @devh0us3

Open source software maintenance is difficult: examples with Go math/rand/v2 and testify

Christophe Colombier — Thu, 02 May 2024 11:07:01 +0000

In this article, I will use Go language as an example, but the subject can be extended to any software with a large codebase and number of users.

Go development team has just published an interesting article about the need to introduce a math/rand/v2 package

Please have a look:

https://go.dev/blog/randv2

While it's not a breaking changes, as it's a v2. It's the first time Go is bringing a v2 package ever. So in more than 15 years!

The article explains why they came to this choice. You can see the struggle they faced in the decision. How they iterated to try to fix issue, how what they did cause other problems, and finally why they had no other choice than bringing a v2.

This article is good and remind me another good one.

Here is a status from the last man standing developer of testify. Testify is popular test asserters library in Go. The code is 10 years old. They are working on a v2 for years, and they announced they have to abandon it.

Comment for #1089

dolmen commented on Nov 15, 2023

A maintainer's manifesto about Testify `v2`

A v2 would please users of v2 because of a cleaner API. A v2 would please maintainers of v2 who are fed-up with flaws in v1's API (traps).

But v2 will be of no help for users of v1 because that will require migration (even just adding /v2 to every import would be a significant and painful migration). With migration (changing code that works) comes a risk of regression. Testify is a set of frameworks for writing testsuites. A testsuite is one critical piece of a software project to protect against regression. The last thing someone wants is a regression in the testsuite that is supposed to protect against regressions.

So users of v1 who can't afford migration (rewrite cost, regression risk...) will just stay with v1. If v1 is abandoned by Testify maintainers who moved to v2, v1 users will just be orphaned.

Testify is very old and has a ton of users that rely on it. At the time of this post (2023-11-15) pkg.go.dev counts 12,454 public packages dependending on it. But this is only the tip of the iceberg as this doesn't count entreprise code hidden behind walls.

To not orphan users of v1, v1 would have to be maintained along with v2. So what is the benefit for maintainers if they have to maintain both v1 and v2? None: only more work while maintenance resources for v1 is already on shortage.

So, as the current only active maintainer, I'm declaring that v2 will never happen. Or at least a v2 of the github.com/stretchr/testify module with such major breaking changes.

Anyone is free to fork the project under a new module name, using changes proposed here or elsewhere, keeping the Testify spirit. This will let users migrate at their own pace. As a maintainer of Testify I will even gladly bless such a fork(s) by linking from testify's documentation (godoc, README). But there is no sane reason for this to happen with the github.com/stretchr/testify module name (the only reason would be branding, but I reject it as a sane reason). Anyway, with how Go modules work, a v2 would already be a module name change. So proponents of breaking changes must just recognize this and just use a fully separate module name.

In this repo we will just continue to maintain v1. Forever.

Olivier Mengué (@dolmen), current only active maintainer of Testify.

PS: @Antonboom is doing an amazing work with testifylint. That is a major tool that helps Testify users to avoid v1's traps. More than a v2.

View on GitHub

You can see how difficult it is to maintain a software that is old, that have a huge number of users.

Go: the future encoding/json/v2 module

Christophe Colombier — Thu, 02 May 2024 10:57:41 +0000

Here is a current implementation of the future encoding/json/v2 in Go

go-json-experiment / json

Experimental implementation of a proposed v2 encoding/json package

JSON Serialization (v2)

This module hosts an experimental implementation of v2 encoding/json The API is unstable and breaking changes will regularly be made Do not depend on this in publicly available modules.

Any commits that make breaking API or behavior changes will be marked with the string "WARNING: " near the top of the commit message. It is your responsibility to inspect the list of commit changes when upgrading the module. Not all breaking changes will lead to build failures.

A Discussion about including this package in Go as encoding/json/v2 has been started on the Go Github project on 2023-10-05. Please provide your feedback there.

Goals and objectives

Mostly backwards compatible: If possible, v2 should aim to be mostly compatible with v1 in terms of both API and default behavior to ease migration For example, the Marshal and Unmarshal functions are the most widely used declarations in the v1…

View on GitHub

This project is not only a proof of concept, but also an idea of the future implementation that will help sorting out many issues with current encoding/json

You get some information in this GitHub issue

https://github.com/golang/go/discussions/63397

📸🔒GitHub: protect your email from spammers with this GitHub privacy setting

Christophe Colombier — Sun, 28 Apr 2024 13:00:00 +0000

First thing to understand, git is not GitHub.

git is a tool, GitHub is somehow an hosting provider. There are many other hosting providers: GitLab, BitBuckets…

A part of git commit is your email.

side note about the email identifier (click to unfold)
You can learn more about it in my previous article

Why you should sign your commits, and not only how.

Christophe Colombier ・ Apr 26

#github #git #security #privacy

Many git tutorials start by the basics:

git config --global user.email you@domain.com

For example this article made by @federicotrotta (hi Frederico 👋)

How To Create a Repository in GitHub

Federico Trotta ・ Apr 24

#beginners #tutorial #git #github

It's OK, but here comes GitHub then.

Because having your email configured in your local git is OK. But commits are made to be pushed.

Here I will only talk about GitHub because it's somehow the reference.

GitHub is public, and it's great, but your email will be publicly available on every of your commit you push on GitHub. ⚠️⚠️

You know what? Evil spammers hidden in the darkness are looking for emails in commits.

Here is how setting everything clean to avoid issues.

Please note, it would only work for new commits, commits you pushed with your real email are already there.

To set up and keep your email private on GitHub, follow these steps:

Open your GitHub profile settings by clicking your profile photo in the upper-right corner of any page, then click "Settings", then "Emails" section.
Set Your Primary Email Address (normally you had set up this when you created your GitHub account):
In the "Primary email address" dropdown menu, select the email address you'd like to associate with your web-based Git operations.
select "Keep my email addresses private". This will provide a no-reply email address (e.g., username@users.noreply.github.com) for your commits.
copy paste it as we will need it in a few steps
Block Command Line Pushes That Expose Your Email (Optional):
If you want to prevent command line pushes that might expose your personal email address, select "Block command line pushes that expose my email". This setting checks the most recent commit's author email and blocks the push if it matches a private email on your GitHub account.
Configure your git settings:
You can do this by running:
```
git config --global user.email "whatever@users.noreply.github.com"
```
Replace "whatever@users.noreply.github.com" with your actual no-reply email address provided by GitHub.

By following these steps, you can ensure that your email address remains private for both web-based and command line Git operations on GitHub

GitHub official documentation about it (click to unfold)

https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/setting-your-commit-email-address#setting-your-commit-email-address-on-github

DEV Community: Christophe Colombier

Follow up: I'm back to dev.to

I'm a dad again 🤩🥳 dev.to pause

Christophe Colombier ・ Apr 26

About the gosec G115 drama, or how I faced back integer conversion overflow in Go 🤯

Christophe Colombier ・ Sep 9

go-safecast: Safe number conversion in Go 🪄

ccoVeille / go-safecast

Safe number conversion in Go: address gosec G115 and cwe-190 Integer Overflow or Wraparound

🪄 go-safecast: safe numbers conversion

Usage

About the gosec G115 drama, or how I faced back integer conversion overflow in Go 🤯

Christophe Colombier ・ Sep 9 '24

Go: integer overflows

About the gosec G115 drama, or how I faced back integer conversion overflow in Go 🤯

git switch and git restore, or why not using git checkout

Git commit helper: add emojis to your commits

Git Commit Message Decoder: New Coder Edition

Muhammad Muzammil Loya ・ May 3

carloscuesta / gitmoji-cli

A gitmoji interactive cli tool for using emojis on commits. 💻

gitmoji-cli

About

Install

npm

brew

Usage

Commit

folke / devmoji

🤖 🚀 ✨ Emojify your conventional commits with Devmoji

✨ Devmoji

📦 Installation

Build your own Octocat avatar, and share your creations on dev.to

The story behind GitHub logo

Christophe Colombier ・ May 3

The story behind GitHub logo

Original GitHub Octocat designer Simon Oxley

2024-05-03 my weekly dev.to recommendation

you are your own maintainer

It Took Me 20+ Years To Learn This Lesson About Dev

Matt Butcher for Fermyon ・ May 1

How to be a better developer for you and the others

Christophe Colombier ・ Apr 7

Discover your cognitive biases 🧠🤔, and how to deal with them 💪🤩 !

Christophe Colombier ・ Apr 22

why and when automating things

Why Automate?

Adam Ross ・ Apr 30

a good article about password management

Password Management: The Basics

Gearoid O'Treasaigh ・ May 2

An interesting and detailed article about code review.

Mastering Code Review: A Guide for Reviewers and PR Creators

Tássio ・ Apr 27

The story behind gzip

The Magical Algorithms Written by Two Old Men, Dominating the World

huizhou92 ・ Apr 26

why you need a rubber duck

Are you Into Rubber Duck Debugging?

Anita Olsen*°•.¸☆ ・ Apr 23

an interesting alternative to classic Readme profile on GitHub

GitHub: Create your own repository landscape ⭐️

Tung Leo ・ Apr 28

a good article article about email protection behind tools, but also privacy

Protect your emails (Short note)

Alex P ・ May 1

Open source software maintenance is difficult: examples with Go math/rand/v2 and testify

Comment for #1089

A maintainer's manifesto about Testify v2

Go: the future encoding/json/v2 module

go-json-experiment / json

Experimental implementation of a proposed v2 encoding/json package

JSON Serialization (v2)

Goals and objectives

📸🔒GitHub: protect your email from spammers with this GitHub privacy setting

Why you should sign your commits, and not only how.

Christophe Colombier ・ Apr 26

How To Create a Repository in GitHub

Federico Trotta ・ Apr 24

A maintainer's manifesto about Testify `v2`