Concern about dependency - cjlapao/common-go

[matt-tyler-qoria]

Hi,

I'm currently reviewing dependencies we used in our applications - partially as a result of supply chain attacks that have occurred over the last year.

I noted one strange dependency that this particular package makes - github.com/cjlapao/common-go/duration.

There does not seem to be anything untoward in either the dependency or how it is used. However this does appear to be a repository that is primarily aimed towards the authors personal use as a collection of their own dependencies they use in their own services, and not something meant to be consumed by the general population.

it's only use is here;

https://github.com/microsoft/kiota-abstractions-go/blob/4d5e39a4e83c32c092caf7f5432d962c9314ac18/serialization/iso_duration.go#L6

and the actual depended on code is below 150 lines.

It may be prudent to instead re-implement the functionality and remove a potential attack vector.

[baywet]

Hi @matt-tyler-qoria Thanks for using kiota and for bringing this up. When I first implemented go, I was extremely surprised there was no standalone implementation of RFC3339 and associated time primitives, and their normalized representation.

Although the structure of this repository is a bit odd, it's been fairly stable. And the owner has been responsive to pull requests.

However, as a precaution, we introduced this wrapper type in case we ever needed to swap the implementation.

Ideally a package for RFC3339/ISO8601 time representations would be created independently of kiota to enable separation of concerns and better reusability.

Or a new one has spawned since the last time I looked at it? Happy to read your additional thoughts on the topic.

[matt-tyler-qoria]

When I first implemented go, I was extremely surprised there was no standalone implementation of RFC3339 and associated time primitives, and their normalized representation.

Ideally a package for RFC3339/ISO8601 time representations would be created independently of kiota to enable separation of concerns and better re-usability.

I agree that this is odd, and something that doesn't seem have gone unnoticed

https://github.com/golang/go/issues/32313

There's some discussion here regarded the json v2 proposal - azure is specifically called out as a user of iso durations.

https://github.com/golang/go/discussions/63397#discussioncomment-7213861

There are a few alternatives around - some of which are mentioned in issue 32313 above. But i think Go suffers in not have a widely accepted package to handle this, and I don't think any of the current alternatives are offering that the current package does.

In that sense it may useful for a koita maintainer to chime in on the above issues as a data point as to its usefulness for standard library inclusion?

[baywet]

Thanks for the additional information . In case it wasn't clear, I am one of the maintainers of Toyota. I suspect the reason why ISO8601 was not implemented because it is not an open standard, you need to pay for the standard papers and what not. After working on the implementation in kiota, I worked with the OpenAPI body to standardize the different formats in a registry. Ideally, we would implement RFC3339 instead of the iso standard and maybe offer a variation for people who are on the iso standard. https://spec.openapis.org/registry/format/duration.html

But we could also wait for the go standard library to add support for those different normalization formats and adopt them whenever they are available.