Additional publishing open source guidance

[NoureenS]

For section: https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/guides/publishing-open-source-code.md#guide-for-publishing-open-source-code-draft

In addition to the GC review before publishing, you may want to include some scrubbing guidance. Unless an individual/department started a project with the intent of releasing an initially private repository, they may need to consider the following:

• adding source code headers that include copyright/license information
• scrubbing the code and comments for any references to internal/confidential information such as internal paths, tools, code names, email addresses, etc.
• Pushing history may contain credentials, prorietary code, and undesirable comments/references --> one can either start with a clone of a new repo and then copy in source files or use other techniques to get the same effect
• Additionally, instead of flipping a private repository to public, one should consider deleting a repo and recreating it (can help remove any sensitive information in issues, PRs, comments, code reviews, wiki pages, etc.) - cleaning up manually may be too difficult and be aware of any hidden data, eg. each repo stores last 300 events - so there may be sensitive data in event timelines if only the visible information is scrubbed
• You may need to check for other open source in your project - are you redistributing something as part of your project? And list the appropriate GC action, such as legal review, required for this scenario

[obrien-j]

+1 on this, and I'd be glad to assist from our work at CSE releasing Assemblyline.

I'd vote strongly against the 'recreate repo', due to the loss of history, but realize that sometimes that might be the most effective route.

You end up losing some of the charm though, https://bitbucket.org/cse-assemblyline/assemblyline/commits/edd3c72bf5049b01aac3a7a65592f3b57551d7d8 ;)

[LaurentGoderre]

I have recreated repo in a way that preserved history. You need to be proficient at git but it is possible.

[gcharest]

Great points @NoureenS !

I think we need to enhance the security dimension. We've broken down 2 sections: Work in the open and Releaseing a Legacy Application (It's just a draft new section, we need more best practice here so don't freak out when reading the text just yet 😆 )

The first section is more around Starting your project in the open and the second is more about the lines of what you mentioned.

I didn't want to go too much in Security as it should apply to both open and closed source software development but we may need to actually go further on the topic.

What do you think? @NoureenS @obrien-j @LaurentGoderre

[NoureenS]

Looks good. Only small tweak suggestion - it doesn't have to be restricted to legacy apps. However one may consider releasing any project, app, snippet that previously was closed source. Regards, Noureen

…

On Wed., May 1, 2019, 3:21 p.m. Guillaume Charest, ***@***.***> wrote: Great points @NoureenS <https://github.com/NoureenS> ! I think we need to enhance the security dimension. We've broken down 2 sections: Work in the open <https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/guides/publishing-open-source-code.md#work-in-the-open> and Releaseing a Legacy Application <https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/guides/publishing-open-source-code.md#publishing-a-legacy-application> (It's just a draft new section, we need more best practice here so don't freak out when reading the text just yet 😆 ) The first section is more around Starting your project in the open and the second is more about the lines of what you mentioned. I didn't want to go too much in Security as it should apply to both open and closed source software development but we may need to actually go further on the topic. What do you think? @NoureenS <https://github.com/NoureenS> @obrien-j <https://github.com/obrien-j> @LaurentGoderre <https://github.com/LaurentGoderre> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHQ53RTZHA277FJZ3ZV3I53PTHUSHANCNFSM4HCBY36Q> .