-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Some more links, structure adjustment and CoC #2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Separated the places that someone would like to get involved, added link to the contribute page and also some info for the Code Of Conduct
README.md
Outdated
| - on our IRC channels #nextcloud & #nextcloud-dev irc://#[email protected] (on freenode) and | ||
| - our forum at https://help.nextcloud.com | ||
|
|
||
| Please read the [Code of Condact](https://nextcloud.com/community/code-of-conduct/). This document offers some guidance to ensure Nextcloud participants can cooperate effectively in a positive and inspiring atmosphere, and to explain how together we can strengthen and support each other. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo, should be "Code of Conduct".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks !
|
@cerebrux can you squash into one commit? |
|
Awesome @cerebrux, great on adding the link to the Code of Conduct! 👍 (Sure, next time squashing into one commit would be good but for now it’s fine. :) @jyaworski thanks for the quick answer! :) |
|
That's awesome! Great work. And nice to have you all in the community @cerebrux @vincchan @jyaworski @jancborchardt ! 🚀 ❤️ 🎉 |
…3129a4c750f5bab40a26e [stable10] Fix mimetype detection inside hidden folders (#26138) (#2…
Improve user list rendering perf by not resorting after every add (#2…
[stable9] Improve user list rendering perf by not resorting after every add (#2…
[stable10] Improve user list rendering perf by not resorting after every add (#2…
Add SPDX header - batch #2
Before this patch, when decrypting a value without using a password, it would call `decryptWithoutSecret` with the system `secret` as `password`. When this fails, it would retry with an empty string as `password`. This has the practical disadvantage that it can lead to confusing error messages. For example, when using the TOTP app, when the system `secret` is misconfigured, the first invocation will throw a sensible `HMAC does not match.` error, but then it is retried and the retry throws a `Hash_hkdf(): Argument nextcloud#2 ($key) cannot be empty` error causing confusion (e.g. https://help.nextcloud.com/t/hash-hkdf-argument-2-key-cannot-be-empty/192556). Of course this fallback to using an empty string is likely part of some sort of graceful migration from the days when the secret could be empty (e.g. nextcloud#34012, nextcloud#31499). However, taking a wider perspective, such 'fallback logic' in security-critical areas makes things more complex, which is a risk. It's not quite the same scenario, but Heartbleed does come to mind. For this reason, rather than a 'surgical' improvement for the particular case encountered above (increasing complexity further), I think it'd be worth to start considering removing this fallback entirely (perhaps in v32.0.0?) - hence this conversation-starter PR. Signed-off-by: Arnout Engelen <[email protected]>
Enhancement: Better previews for HDR video (attempt #2)
# This is the 1st commit message: feat(snowflake): extend Entity class to support snowflakes RFC: extending the Entity class to support snoflake IDs automagically Good ides - yes / no? Benefits: - every entity that supports snowflake IDs can automagically handle them by implementing the `SnowflakeAwareEntity` instead of the regular `Entity` - No adding IGenerator / IDecoder in every entity class - centralised method support for `createdAt`, `setId`, and anything else we would like to offer separately - get entire decoded snowflake id from the entity Drawbacks: - Will it work the way I think it should? Signed-off-by: Anna Larch <[email protected]> # The commit message #2 will be skipped: # fixup! feat(snowflake): extend Entity class to support snowflakes # The commit message #3 will be skipped: # fixup! feat(snowflake): extend Entity class to support snowflakes # The commit message #4 will be skipped: # fixup! feat(snowflake): extend Entity class to support snowflakes # The commit message #5 will be skipped: # fixup! feat(snowflake): extend Entity class to support snowflakes # The commit message #6 will be skipped: # fixup! feat(snowflake): extend Entity class to support snowflakes # The commit message #7 will be skipped: # fixup! feat(snowflake): extend Entity class to support snowflakes # The commit message #8 will be skipped: # fixup! feat(snowflake): extend Entity class to support snowflakes # The commit message #9 will be skipped: # fixup! feat(snowflake): extend Entity class to support snowflakes # The commit message #10 will be skipped: # fixup! feat(snowflake): extend Entity class to support snowflakes # The commit message #11 will be skipped: # fixup! feat(snowflake): extend Entity class to support snowflakes # The commit message #12 will be skipped: # fixup! feat(snowflake): extend Entity class to support snowflakes # The commit message #13 will be skipped: # fixup! feat(snowflake): extend Entity class to support snowflakes # The commit message #14 will be skipped: # fixup! feat(snowflake): extend Entity class to support snowflakes # The commit message #15 will be skipped: # fixup! feat(snowflake): extend Entity class to support snowflakes # The commit message #16 will be skipped: # fixup! feat(snowflake): extend Entity class to support snowflakes
Separated the places that someone would like to get involved, added link to the contribute page and also some info for the Code Of Conduct