Closed tecknicaltom closed 11 years ago
Resources to reference for improvoing these articles:
couple more C# related references
This is now tracked in: https://github.com/TMContent/Lib_All/issues/6
I'm not sure why this is referencing a different GitHub organization, but it does not appear that I (or likely others in Seattle) have access to it
The TMContent is an org for TM content..This was split for easier conceptual organisation of repos. The access part should be fixed. Serge, could you give Seattle guys access to this org?Or do you want me to do this?
On Thu, Feb 7, 2013 at 11:52 PM, Tom Samstag notifications@github.comwrote:
I'm not sure why this is referencing a different GitHub organization, but it does not appear that I (or likely others in Seattle) have access to it
— Reply to this email directly or view it on GitHubhttps://github.com/TeamMentor/Master/issues/136#issuecomment-13245489.
still no access
Roman, I do not see any reason to have an organization other than Security Innovation for bugs on Security Innovation content. Can you please explain why this isn't tracked here?
Content related issues are now tracked in the repository where the relevant content is stored.
This repo (TeamMentor/Master) is for code issues (note that there are no data/articles in it)
Dinis Cruz
On 7 Feb 2013, at 21:08, meta notifications@github.com wrote:
Roman, I do not see any reason to have an organization other than Security Innovation for bugs on Security Innovation content. Can you please explain why this isn't tracked here?
— Reply to this email directly or view it on GitHub.
Keeping the issues with the content makes perfect sense. The question was: why are you (plural) using a different organization? Security Innovation is the organization that owns anything related to TM (code, content, ...) and it can have as my repos as it likes (code, content, ..). So why is there another organization? It's likely that you have a reason, but that reason is not obvious. Please share with the class ;)
We already had a massive thread about this, unfortunately I think it was on a place I can't easy link to :(
Roman, is that diagram on tm4tm up-to-date with the current/desired GitHub structure?
Dinis Cruz
On 7 Feb 2013, at 21:18, meta notifications@github.com wrote:
Keeping the issues with the content makes perfect sense. The question was: why are you (plural) using a different organization? Security Innovation *is
— Reply to this email directly or view it on GitHubhttps://github.com/TeamMentor/Master/issues/136#issuecomment-13260287.
Ahhh I see. Well, it's unfortunate that the conversation did not result in a simple understanding that can be shared. I will leave you all to it, but I think the typical Github model of one organization and multiple repositories makes more sense. Cheerio.
can we add "higher complexity of github user permissions management" to the list of strikes against multiple github organizations? (I still don't have access to the linked issue above. is the link correct or are the permissions not right?)
bump (still no access)
Hi Tom
I just created a group for you (and SI AppSec Team) at the TMContent organization.
You should now have access to https://github.com/TMContent/Lib_All/issues and https://github.com/TMContent/TM4TM/issues
Tom, do you guys now have access to the new Org? In short, the purpose for the new Org was to keep logical separation between content, code and client specific repo's. Ideally they should all be in one org, however there is no concept for domains in github. (at least we didn't see any). Here is a diagram I drew up a while ago of how github structure would look like. This is more conceptual rather then actual at this point. But the big picture is there. http://tm4tm.teammentor.net/article/00000000-0000-0000-0000-000000499c09
yes, sorry for the late reply, but access works.
The github structure is unexpected and nonintuitive to most users of github because to regular users of github, your multiple orgs are expected to be multiple repos, and your multiple repos are expected to be multiple branches. But that's unrelated to this issue and a conversation that has been already hashed out.
I looked through all of the articles in the "15 Poor Password Storage" library of services.teammentor.net (which I assume all came from the main set of TM content) and all articles talked about using SHA256+salt for password hashing. Some mention manually repeating the hash for multiple iterations. This is not in line with what we traditionally recommend to customers and what is currently best practice. SHA256 is too fast of a hash and we generally recommend avoiding direct use of general purpose hashes for password hashing. None of the articles mentioned the use of PBKDF2, scrypt, or bcrypt for password hashing, which is what we generally recommend.