-<% - has_branches = (!@repository.branches.nil? && @repository.branches.length > 0) - sep = '' - %> + <% if @changesets && !@changesets.empty? %> + <%= render partial: 'revisions', + locals: { project: @project, path: @path, + revisions: @changesets, entry: nil } %> + <% end %> +
+ <% + has_branches = (!@repository.branches.nil? && @repository.branches.length > 0) + sep = '' + %> -<% if @repository.supports_all_revisions? && @path.blank? %> -<%= link_to t(:label_view_all_revisions), revisions_project_repository_path(@project) %> -<% sep = '|' %> -<% end %> -
+ <% if @repository.supports_all_revisions? && @path.blank? %> + <%= link_to t(:label_view_all_revisions), revisions_project_repository_path(@project) %> + <% sep = '|' %> + <% end %> + <% end %> <% html_title(t(:label_repository)) -%> diff --git a/docs/development/concepts/secure-coding/README.md b/docs/development/concepts/secure-coding/README.md new file mode 100644 index 000000000000..847857ebbdbd --- /dev/null +++ b/docs/development/concepts/secure-coding/README.md @@ -0,0 +1,241 @@ +--- +sidebar_navigation: + title: Secure coding guidelines +description: An introduction and description of guidelines for writing secure code at OpenProject and preventing common security vulnerabilities. +keywords: infrastructure, security, coding, guidelines +--- + + + +# Secure coding Guidelines + +This document provides secure coding development guidelines for developers working on OpenProject. The objective is to help identify and mitigate potential security vulnerabilities early in the development process. This document is based on the best practices following the [Open Web Application Security Project (OWASP)](https://www.owasp.org). + +By following these guidelines, developers can contribute to OpenProject while ensuring the security of OpenProject and reduce the risk of vulnerabilities being released into production. + +The following guidelines are a starting point for developers interesting in contributing in OpenProject to ensure they are developing secure code. We recommend to refer to the [OWASP cheat sheets](https://cheatsheetseries.owasp.org/) as well as the [OWASP Top Ten](https://owasp.org/www-project-top-ten/) for the most recent and detailed guidelines. The following sections are heavily inspired and cross-referencing the well-known recommendations from the the OWASP, each section providing links for further references to generic, Rails-centered as well as OpenProject-specific information when available. + +By adhering to these secure coding development guidelines, contributors to OpenProject can help to significantly reduce the risk of adding potentially unsecure code. Regardless of these guidelines, be mindful when reviewing pull requests of features touching any of these guidelines, keep security in mind whenever you write new code for OpenProject to ensure we deliver a secure and trustworthy software. + +The guidelines mentioned below are implemented by OpenProject currently when not specified differently. + + + +## Authentication and Credentials + +Implement strong authentication mechanisms for any sensitive credentials to be used in OpenProject. Currently these credentials are one of: + +- A user's own login and password for direct logins +- Access tokens for API, OAuth, or external integrations +- Session cookies + + + +**Risks and Impacts** + +- *Unauthorized Access:* Attackers could gain unauthorized access on improper authentication mechanisms to protected resources, user accounts, or administrative functions. Resulting consequences are data breaches, unauthorized actions, and potential exposure of sensitive information. +- *Authentication Bypass:* Flaws in authentication logic can permit attackers to bypass the authentication process. Resulting consequences are the same as *Unauthorized Access*. +- *Credential Theft or Stuffing:* Weak authentication methods may lead to attackers stealing user credentials (e.g., usernames and passwords) or reusing from credentials exploited on other services. Consequences are unauthorized access, account hijacking, and potential misuse of user accounts. +- *Brute Force Attacks:* Insufficient protection against brute force attacks can allow attackers to guess or crack passwords. This could result in account lockouts or takeovers despite otherwise sound mechanisms. +- *Insecure Password Storage*: Storing passwords improperly (e.g., in plaintext or in outdated or incorrectly constructed cryptographic hash functions) can expose them to theft in case of data breaches. This in turn could result in a mass compromise of account data. +- *Insufficient Multi-Factor Authentication (MFA):* Lack of MFA support makes it easier for attackers to compromise accounts with stolen credentials. This results in reduced account security and higher risk of unauthorized access. + + + +**Guidelines** + +- Ensure uniqueness and case-insensitivity of user logins. +- Use crytographic hashes for password or credentials storage +- Allow administrators to enforce strong password policies with a combination of characters, numbers, and special symbols. Implement password expiration and account lockout mechanisms. +- Implement mechanisms to protect against brute force attacks, such as account lockouts, rate limiting, or increasing delays after multiple failed login attempts. +- Use strong password controls and validations +- Provide secure mechanisms for account recovery, such as sending a reset link to the user's registered email address. Avoid leaking the existence of user accounts by always returning the same response. +- Provide means of auditing, maintaining detailed logs of authentication events, including successful and failed login attempts. Log sufficient information for auditing and incident response. +- Use the provided features by Rails to prevent cross-site request forgery (CSRF) attacks by utilizing anti-CSRF tokens for all state-changing requests and ensuring that authentication requests are immune to CSRF. + + + +**Usage at OpenProject** + +OpenProject uses industry standard authentication mechanisms that follow the best practices and are the de-facto norm for many organizations: + +- External authentication providers using OpenID connect protocols or SAML 2.0 protocol +- External authentication through LDAP user binds, optional LDAP user and group membership synchronization (Enterprise-Edition add-on) +- OAuth 2.0 application authentication and authorization with OpenProject acting as the authorization server. Access tokens are hashed using SHA256 in the database. +- Internal user credential authentication against passwords stored in BCrypt with a high default yet configurable cost factor depending on the organizational requirements. + + + +**References** + +https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html + +https://guides.rubyonrails.org/security.html + + + +### Session Management + +As OpenProject is a web application, the web session is the central mechanism of authentication for users using the application with their browser. A secure session cookie is used to identify a user's active session. + +**Risks and Impacts** + +- *Session Hijacking:* Attackers may steal or manipulate active user session identifiers, gaining unauthorized access to user accounts or sensitive areas of the application. Resulting consequences are unauthorized access, data exposure, and potential misuse of user accounts. + +- *Session Fixation:* Vulnerabilities that allow session fixation attacks can enable attackers to set a user's session ID and take control of their session. Resulting consequences are unauthorized access, data manipulation, and session theft. + +- *Improper Session Timeout:* Inadequate session timeout settings can lead to prolonged active sessions, increasing the window and surface of opportunity for attackers. Resulting consequences are exposure to session-related attacks and unauthorized access. + +- *Insecure Session Storage:* Storing session data insecurely (e.g., in client-side storage or without proper care) can expose it to theft or tampering. Potential impacts are unauthorized data access or manipulation, data breaches, and privacy violations. + +- *Insufficient Session Revocation:* Lack of proper mechanisms to revoke or terminate user sessions can result in prolonged access for users who should no longer have it. Potential impacts are unauthorized access to protected resources and data. + +- *Cross-Site Scripting (XSS) and Session Theft:* If an application is vulnerable to XSS attacks, attackers can steal session identifiers and impersonate users. + +- *Lack of Session Regeneration:* Failure to regenerate session identifiers upon login or privilege changes can expose users to session fixation attacks. + +- *Session Data Tampering:* Inadequate session data validation and protection can lead to attackers modifying session attributes to gain unauthorized privileges. + +- *Weak Session Tokens:* Weak or predictable session token generation can make it easier for attackers to guess or brute-force session identifiers. + + + +**Guidelines** + +- Use Rails' built-in secure session cookies for maintaing the users' session. It incorporates best-practices to ensure strong session tokens, tamper resistance, and proper expiration. +- Ensure session cookies are marked `secure` and `httponly`, as well as providing the appropriate `SameSite` and expiry flags according to the instance's configuration. +- Provide a secure logout mechanism that invalidates the session and clears session cookies. Ensure that users are logged out after a period of inactivity. +- Implement session fixation protection mechanisms to prevent attackers from fixing a user's session to a known value. +- Prevent storing sensitive unencrypted session information on the client device +- Allow users to terminate sessions themselves, as well as allow instances to prevent simultaneous session logins by terminating other sessions. +- Implement strong Cross-site scriptiong (XSS) protections as listed further down below, as the target of XSS attacks is often exploitation of the user's session credential. + +**References** + +https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html + + + +## Authorization and Access Control + +At its core, permissions in OpenProject are the central key to determine who can access which projects and modules of an instance, as well as what actions they can perform on these pages. OpenProject application uses a Role-based access control (RBAC) approach to grant individual users permissions to projects. The risks associated with security vulnerabilities in the authorization code can have serious implications for the security. + +**Risks and Impact** + +- *Unauthorized access*: Users gaining or exploting access to sensitive resources or functionalities they are not supposed to have access to. Potential consequences in data breaches, unauthorized actions, and potential exposure of confidential information. +- *Over-Privileged Users*: Users receiving more permissions than necessary for their role, leading to potential misuse of privileges. Potential consequencse are unauthorized data modifications, data leaks, or abuse of system capabilities. + + + +**Guidelines** + +- Allow flexible assignment of permissions for individual projects and objects, following the *Least Privilege* rule. +- Implement controlls and authorization checks with a *Deny by default* or *Fallback deny* rule, preventing authorization flows to miss certain steps and allowing user requests to fall through the authorization checks. +- Validate the permissions of a user on every request, regardless of the origin of it. +- Enforce proper authorization controls to ensure that users only access their own data. +- Provide extensive tests for permission checks, making assertions of all available cases and using visibility testing for asserting that certain actors _cannot_ access data or perform actions. +- Regularly review and update access controls to reflect changes in application functionality and roles. + + + +**References** + +https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html + +https://guides.rubyonrails.org/security.html + + + +## User Input Validation + +OpenProject is a form-driven application, meaning that users input a lot of data into the system to use it. Proper validation and encoding of user input is crucial to ensure data can be processed in a responsible way. + + + +**Risks and Impacts** + +- *Injection attacks:* Attackers could inject malicious code or payloads into the application, leading to vulnerabilities such as SQL injection, or OS-level command injection. Potential consequences are unauthorized data access, data manipulation, and potentially complete system compromise. +- *Cross-site scripting (XSS)*: Failure to validate and sanitize user inputs can allow malicious scripts to be executed in the context of other users' browsers. Potential consequences are: Theft of sensitive user data, session hijacking, and potential defacement or compromise of the web application. +- *Cross-Site Request Forgery (CSRF):* Lack of proper request validation can make it easier for attackers to trick users into performing unintended actions on their behalf. Potential consequences are unauthorized actions, such as account changes, data deletion, or fund transfers, performed without user consent. +- *File Upload Vulnerabilities*: Insufficient input validation on file uploads can lead to arbitrary file uploads, enabling attackers to upload malicious files or execute code. Potential consequences are remote malware distribution, and remote code execution. + + + +**Guidelines** + +- Understand and use the [Rails framework's mechansims](https://guides.rubyonrails.org/security.html#injection) to prevent injection and CSRF attacks +- Understand and use the Rails framework to use its built-in security measures such as proper encoding of HTML output, CSRF tokens in all state-changing requests, and automatic escaping of user input in ActiveRecord SQL queries. +- Implement a strict [content security policy](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) to mitigate common XSS, CSRF and similar cross-site attack vectors. OpenProject uses the [secure_headers gem](https://github.com/github/secure_headers) to define its CSP. +- Learn about the [different types of XSS](https://owasp.org/www-community/Types_of_Cross-Site_Scripting#stored-xss-aka-persistent-or-type-i) and their impacts: Reflected XSS, Stored XSS, Dom-based XSS and server vs client side XSS +- Implement file upload filters based on file type, and ensure user-provided files cannot be executed as code. +- Ensure transmission of confidential data does not happen through GET requests, but use POST/PUT/PATCH requests instead. + +**References** + +https://guides.rubyonrails.org/security.html#injection + +https://owasp.org/www-community/Types_of_Cross-Site_Scripting#stored-xss-aka-persistent-or-type-i + +https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html + +https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html + + + +## External dependencies + +OpenProject includes a number of external dependencies both in Ruby as well as in the JavaScript ecosystem. Regardless of the selection of these dependencies, maintaining and keeping the dependencies up-to-date is a critical part of the security of the application. We have seen a lot of attacks surface in the past years originating from either outdated or manipulated dependencies. + +**Risks** + +- *Outdated code or known Vulnerabilities*: Older versions of libraries or dependencies may have publicly disclosed vulnerabilities. If these known vulnerabilities are not patched, they can be readily exploited by attackers. +- *Increased Attack Surface*: Over time, libraries can become bloated with features, some of which may not be needed in OpenProject. This increases the overall attack surface, making the application more vulnerable to potential attacks. +- *Lack of Support*: Outdated libraries may no longer be maintained. This means no more security updates, bug fixes, or support from the developer community. +- *Legacy Code and Deprecated Functions*: Outdated dependencies might utilize functions or methods that have since been deprecated or replaced without OpenProject developers being aware of that fact, leading to unreliable or unsafe code practices. +- *Reduced Performance*: Newer versions of libraries often come with performance improvements. Using outdated dependencies can lead to inefficiencies or bottlenecks in the application. +- *Increased maintenance burden*: With a rising number of dependencies that are outdated or unmaintained, providing a secure upgrade path becomes harder due to e.g., newer versions of Rails or Ruby no longer being compatible with the gem or package in question. +- *Chain of Dependencies*: Some dependencies rely on other dependencies. Using an outdated library might cause a cascading effect where multiple parts of your application become outdated and vulnerable. Also, selection of dependencies is important to minimize attack vectors. Every platform handles this differently. + +**Guidelines** + +- *Automate Updates*: Use and maintain automated tools such as Dependabot and workflows that check for dependency updates regularly, and run tests when updates are available. Before updating the dependencies, review its changelog or release notes to understand changes and potential impacts on your application. +- *Manual update checking:* For pinned versions, use `npm outdated`, `bundle outdated` or `npm-check-updates `to ensure you staay on top of new versions and see if breaking changes ocurred. +- *Lockfile integrity*: Use `package-lock.json` and `Gemfile.lock` to pin exact version for a released version of OpenProject, ensuring that all environments use the same versions. +- *Stay Informed*: Subscribe to mailing lists, newsletters, or vulnerability databases to receive timely information on crucial updates or security patches so that updates can be performed as fast as possible. +- *Vet new dependencies*: Before adding a new gem or package, research its maintenance history, last update, known vulnerabilities, and community reviews. Check if it's actively maintained, and evaluate all the alternatives. +- *Remove outdated dependencies* :Only include gems and packages that are absolutely necessary for your project. Less dependencies mean a reduced attack surface. Remove libraries if they become unused. + + + +**References** + +https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html + + + +## Logging and Error Handling + +Inconsiderate use of error handling, logging, and monitoring mechanisms of a web frameworks can lead to the following risks and impacts. + +**Risks and Impacts** + +- *Information Disclosure:* Improper error handling may reveal sensitive information or internal details about the application's infrastructure. Resulting consequences are Exposure of sensitive data, such as database errors or stack traces, which can aid attackers in planning further attacks. +- *Data Leakage:* Inadequate logging and error handling can inadvertently log sensitive user data or credentials. This may result in unauthorized access to user data, privacy violations, and compliance breaches. +- *Log Injection Attacks:* Lack of input validation on log entries can expose the application to log injection attacks where attackers manipulate log entries to inject malicious code or content. Resulting impacts are Malicious code execution, log manipulation, and potential system compromise. + +**Guidelines** + +- Implement proper exception handling to catch and handle unexpected errors. Log the exceptions for further analysis. +- The application should fail in a secure manner. If an error occurs, the system should revert to a safe state that doesn't expose sensitive information or functionality. +- Use generic error messages for end users to prevent information leakage. Avoid exposing stack traces, database error messages, or any detailed system information. If providing summaries or error reports to users, make sure no sensitive data or system information is included. +- Scrub and filter user data being logged or output in error messages to prevent data leakage. +- Only log necessary information. Avoid logging sensitive data such as passwords, payment information, or Personally Identifiable Information (PII). +- Log data in a standard format to make parsing, auditing, and monitoring of that information easy. + + + +**References** + +https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html + +https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html diff --git a/docs/development/data-flow/README.md b/docs/development/data-flow/README.md new file mode 100644 index 000000000000..f13e1f7d65ef --- /dev/null +++ b/docs/development/data-flow/README.md @@ -0,0 +1,100 @@ +# Data flow and Usage + +Regardless of the type of installation of OpenProject, the following diagram provides a high-level overview of through which systems data related to OpenProject is flowing. + + + +```mermaid +%%{init: {'theme':'neutral'}}%% + +flowchart TD + A[Client Browser] -->|"HTTP(s) requests"| B(Load Balancer / Proxy) + A1[API or Native clients] -->|"HTTP(s) requests"| B(Load Balancer / Proxy) + A2[SVN or Git clients] -->|"HTTP(s) requests"| B(Load Balancer / Proxy) + B -->|Proxy| openproject + + subgraph openproject[OpenProject] + C[Puma app server] + D[Background worker] + end + + + subgraph integrations[External integrations] + O[Other integrations] + N[Nextcloud] + end + + subgraph services[Services] + M[memcached] + P[PostgreSQL] + S[Object storage or NFS] + end + + + openproject <--> services + openproject --> integrations + B <--> integrations + +``` + +As a web application, the primary data flow is between the Client browser (or attached API clients) through an external proxying web server (this might be a load balancer or proxying server). We're assuming it is the one responsible for terminating TLS connections for the course of this document - although encrypted connections between Load balancer and Puma server are possible. In case of packaged or kubernetes installations, this proxying server might be part of the OpenProject stack (e.g., an Apache2 packaged installation server or nginx ingress). + +The external web server acts as a proxy/reverse-proxy for the OpenProject Puma application server, relaying requests for it to handle and respond. In the course of the request, access to external services such as the PostgreSQL database, a caching server, or attached storages might be performed. In case of S3-compatible object storage set ups, OpenProject performs calls to the object storage to put or request files from it. Likewise, for network-attached storages linked into the application, underlying network requests are performed. These are out of scope for this evaluation, as they are provided and maintained by the operator of the system. + +In the course of using the application, background tasks are enqueued in the database such as outgoing emails, cleanup tasks, or notification processing. These tasks are performed in a separate process, the background worker queue. This process accesses the same services as the application server process to access or modify data. It might connect to external integrations such as a Nextcloud instance to set up file sharings depending on actions performed by the users. + + + +## Schema information + +OpenProject's database schema is considered an internal API, please do not rely on it as a stable point of references. Schema modifications by the OpenProject core might be performed in any upgrade, including patch releases. Modifications to the database schema are considered a third-party customization and might prevent us from giving proper support. If you have an active support contract with OpenProject, please note that modifications affect our warranty. For more information, please consult the [Terms of Services](https://www.openproject.org/legal/terms-of-service/#-5-warranty). + +We recommend you use existing database tools to inspect and export the database as an ERD. That being said, we've prepared an export of an ERD of the current state of the database. Note that this diagram is not regularly updated. Use tools like IntelliJ database explorer or [mermerd](https://github.com/KarnerTh/mermerd) to generate a live ERD of your database set up instead. + +[](openproject-erd.jpg) + + + +# Use of technical cookies + +OpenProject makes use of technical cookies to identity the browser client and/or remember information such as 2FA login state. The core application makes use of these cookies: + +- `_open_project_session` (the name is configurable) contains the information about the logged in user as well as information stored between requests on the user's choices (e.g. the filters for costs are in part stored there) +- `autologin` enables the user to automatically log in again after the session expired (e.g. because the browser was closed). It is set when the user checks the 'Stay logged in' box in the login form. +- `op2fa_remember_token` the presence of that cookie suppresses the need for the user to provide a second factor upon login for 30 days if the user selects to do so when entering the 2fa information. + +On top of that, for cloud instances: + +- `openproject_cloud_instances` contains a list of instances the user recently accessed. +- additional technical cookies might be set by the load balancer and intermediate processes (i.e., to remember a sticky load balancer and ensuring subsequent requests are routed similarly). + + + +# Processing of Personally Identifiable Information + +As OpenProject is dealing with user account data, it is processing personally identifiable information (PII). This data encompasses: + +- User's first and last name +- E-Mail address(es) +- Other uniquely identifiable information used as authentication data of external identity providers (such as SAML or OpenID Connect) +- User pictures / Avatars +- IP addresses in log files +- Possibly data that is filled as part of user custom fields, configurable data fields shown and editable for users. The content of these fields are user-provided and not systematically processed by OpenProject however. + + + +Affected services: + +- PostgreSQL database (stores user account data) +- Object storage or NFS (stores user pictures as files) +- Memcached (Might contain references to cached information of user data) + + + +## Deletion and Anonymization of PII + +Whenever users in OpenProject are fully deleted, the system scrubs and removes all structural PII. For more information on user account deletion, please see [the user administration guide](../../system-admin-guide/users-permissions/users/#delete-users). + +Deleting a user account is a permanent action and cannot be reversed. All actions performed in the name of the user are being scrubbed and replaced with a singular "Deleted user" reference in order to maintain integrity of database references, such as being an author of a work package that remains. Finally, the user data itself will be deleted, removing all structural traces of PII in the system. Due to the user references changing, respective cache keys for information such as work packages or projects are invalidated automatically. Note that user-input data such as text or comments cannot be deleted or scrubbed in an automated fashion. + +Log files might still retain PII data of the user for the configured retention period. Memory references in memcached might still refer to (invalidated) user data until it is being reassigned. diff --git a/docs/development/data-flow/openproject-erd.jpg b/docs/development/data-flow/openproject-erd.jpg new file mode 100644 index 000000000000..d5ad108d5a4e Binary files /dev/null and b/docs/development/data-flow/openproject-erd.jpg differ diff --git a/docs/development/development-environment-ubuntu/README.md b/docs/development/development-environment-ubuntu/README.md index 30a784ef5749..406730584ff7 100644 --- a/docs/development/development-environment-ubuntu/README.md +++ b/docs/development/development-environment-ubuntu/README.md @@ -99,7 +99,7 @@ Next, install a PostgreSQL database. Create the OpenProject database user and accompanied database. ```shell -sudo su postgres +sudo su - postgres [postgres@ubuntu]# createuser -d -P openproject ``` You will be prompted for a password, for the remainder of these instructions, we assume its `openproject-dev-password`. diff --git a/docs/getting-started/my-account/README.md b/docs/getting-started/my-account/README.md index 1fd6a6451639..1c0f4d57546e 100644 --- a/docs/getting-started/my-account/README.md +++ b/docs/getting-started/my-account/README.md @@ -35,7 +35,7 @@ Choose **My account**. ## Edit your user information To change your email address or your name, navigate to **Profile** on the left side menu of **My account** page. -Here you can update the information and **save** your changes. +Here you can update the information and **save** your changes. If you're changing the email address of your account, you will be requested to confirm your account password before you can continue. (Note: This applies only to internal accounts where OpenProject can verify the password).  @@ -106,6 +106,8 @@ In order to register a new device for two-factor authentication, click the green To receive the second factor, you can use an authentication app on your mobile phone, such as Google Authenticator or Authy. You have to enter the code that is displayed in the authentication app to your login. +You can remove or approve 2FA applications by confirming your password. Note that this applies only to internally authenticated users. + ### Backup codes If you are unable to access your two-factor devices, you can use a backup code to regain access to your account. Use the grey button **Generate backup codes** to generate a new set of backup codes. diff --git a/docs/release-notes/13-0-2/README.md b/docs/release-notes/13-0-2/README.md new file mode 100644 index 000000000000..302e64439c9d --- /dev/null +++ b/docs/release-notes/13-0-2/README.md @@ -0,0 +1,52 @@ +--- +title: OpenProject 13.0.2 +sidebar_navigation: + title: 13.0.2 +release_version: 13.0.2 +release_date: 2023-09-07 +--- + +# OpenProject 13.0.2 + +Release date: 2023-09-07 + +We released [OpenProject 13.0.2](https://community.openproject.com/versions/1868). + +This release contains several bug fixes. One of them we consider of high importance. We recommend updating to the newest version. + +That important bug affected only OpenProject instances that use the +"Project folder" feature of the Nextcloud integration. That feature was +introduced just recently in version 13.0. We recommend an immediate update for all OpenProject instances that already make use of the "Project folder" feature. + +The bug potentially gave OpenProject users access to project folders where +they should not. To receive this erroneous access, users need to rightfully have access to at least one other project folder. The permissions for that project folder are mistakenly copied over +to other project folders. + +This only affects those users that have granted OpenProject access to their Nextcloud user via OAuth. Other users that do not have access rights to any project folder and have not granted access to Nextcloud via OAuth are not affected. + + +#### Bug fixes and changes + +- Fixed: [AppSignal] Performance MessagesController#show \[[#47871](https://community.openproject.com/wp/47871)\] +- Fixed: Number of wp no longer shown in bars on the graph \[[#49767](https://community.openproject.com/wp/49767)\] +- Fixed: Not optimal texts for activity entry for migrated file links \[[#49770](https://community.openproject.com/wp/49770)\] +- Fixed: Description in a box having too little height when the browser window's width is decreased \[[#49831](https://community.openproject.com/wp/49831)\] +- Fixed: "share_calendars" permission does not register dependencies and contract actions \[[#49833](https://community.openproject.com/wp/49833)\] +- Fixed: OAuth remapping of existing users using case sensitive login match while user registration does not \[[#49834](https://community.openproject.com/wp/49834)\] +- Fixed: Users SEEM to be able to reset password for invited, not yet activated accounts \[[#49836](https://community.openproject.com/wp/49836)\] +- Fixed: Fix untranslated strings \[[#49848](https://community.openproject.com/wp/49848)\] +- Fixed: Switch branch in repository doesn't do anything \[[#49852](https://community.openproject.com/wp/49852)\] +- Fixed: `packager:postinstall` task fails, if `OPENPROJECT_HOST__NAME` is set in environment \[[#49867](https://community.openproject.com/wp/49867)\] +- Fixed: Eager loading for API not working in parts leading to degraded performance \[[#49915](https://community.openproject.com/wp/49915)\] +- Fixed: Docker instance: No svn present in v13? \[[#49930](https://community.openproject.com/wp/49930)\] +- Fixed: Add in all reported missing translations \[[#49937](https://community.openproject.com/wp/49937)\] +- Fixed: Accidentaly granting access to Nextcloud project folders that are no members of the project \[[#49956](https://community.openproject.com/wp/49956)\] +- Changed: Forbid user to enable misconfigured storages for a project. \[[#49218](https://community.openproject.com/wp/49218)\] +- Changed: Remove the "show" view for a storage's settings page \[[#49676](https://community.openproject.com/wp/49676)\] + +#### Contributions +A big thanks to community members for reporting bugs and helping us identifying and providing fixes. + +Special thanks for reporting and finding bugs go to + +Bernhard Kroll, Mario Haustein, Markus K. diff --git a/docs/release-notes/README.md b/docs/release-notes/README.md index 4840309114d7..e0c7593b8865 100644 --- a/docs/release-notes/README.md +++ b/docs/release-notes/README.md @@ -14,6 +14,13 @@ Stay up to date and get an overview of the new features included in the releases +## 13.0.2 + +Release date: 2023-09-07 + +[Release Notes](13-0-2/) + + ## 13.0.1 Release date: 2023-08-29 diff --git a/frontend/src/global_styles/content/_autocomplete.sass b/frontend/src/global_styles/content/_autocomplete.sass index 5c0250c3b44b..a725621b7b1b 100644 --- a/frontend/src/global_styles/content/_autocomplete.sass +++ b/frontend/src/global_styles/content/_autocomplete.sass @@ -61,6 +61,7 @@ div.autocomplete // -------------------------- ng-select -------------------------- .ng-select width: 100% + font-size: var(--body-font-size) .ng-value-container min-height: 2rem @@ -115,6 +116,7 @@ div.autocomplete .ng-option line-height: 22px + font-size: var(--body-font-size) .op-avatar margin-right: 8px diff --git a/frontend/src/stimulus/controllers/dynamic/repository-navigation.controller.ts b/frontend/src/stimulus/controllers/dynamic/repository-navigation.controller.ts index 079ec6436863..d433509fc2ac 100644 --- a/frontend/src/stimulus/controllers/dynamic/repository-navigation.controller.ts +++ b/frontend/src/stimulus/controllers/dynamic/repository-navigation.controller.ts @@ -67,12 +67,20 @@ export default class RepositoryNavigationController extends Controller { } sendForm() { - this.branchTarget.disabled = true; - this.tagTarget.disabled = true; + if (this.hasBranchTarget) { + this.branchTarget.disabled = true; + } + if (this.hasTagTaget) { + this.tagTarget.disabled = true; + } this.formTarget.submit(); - this.branchTarget.disabled = false; - this.tagTarget.disabled = false; + if (this.hasBranchTarget) { + this.branchTarget.disabled = false; + } + if (this.hasTagTaget) { + this.tagTarget.disabled = false; + } } /** diff --git a/lib/tasks/packager.rake b/lib/tasks/packager.rake index e07d70256ae4..ef934c820104 100644 --- a/lib/tasks/packager.rake +++ b/lib/tasks/packager.rake @@ -63,7 +63,7 @@ namespace :packager do # Persist configuration Setting.sys_api_enabled = 1 Setting.sys_api_key = ENV.fetch('SYS_API_KEY', nil) - Setting.host_name = ENV.fetch('SERVER_HOSTNAME', Setting.host_name) + Setting.host_name = ENV.fetch('SERVER_HOSTNAME', Setting.host_name) if Setting.host_name_writable? # SERVER_PROTOCOL is set by the packager apache2 addon # other SERVER_PROTOCOL_xxx variables can be manually set by user diff --git a/modules/storages/app/services/storages/group_folder_properties_sync_service.rb b/modules/storages/app/services/storages/group_folder_properties_sync_service.rb index 9121bca26381..fc4483d51339 100644 --- a/modules/storages/app/services/storages/group_folder_properties_sync_service.rb +++ b/modules/storages/app/services/storages/group_folder_properties_sync_service.rb @@ -197,35 +197,41 @@ def group_users end def project_folder_permissions(project:) + { + users: admins_project_folder_permissions.merge!(members_project_folder_permissions(project:)), + groups: { "#{@group}": NO_PERMISSIONS } + } + end + + def admins_project_folder_permissions + @admin_nextcloud_usernames.each_with_object( + "#{@nextcloud_system_user}": ALL_PERMISSIONS + ) do |admin_nextcloud_username, hash_map| + hash_map[admin_nextcloud_username.to_sym] = ALL_PERMISSIONS + end + end + + def members_project_folder_permissions(project:) + tokens_query(project:).each_with_object({}) do |token, permissions| + nextcloud_username = token.origin_user_id + permissions[nextcloud_username.to_sym] = calculate_permissions(user: token.user, project:) + @nextcloud_usernames_used_in_openproject << nextcloud_username + end + end + + def tokens_query(project:) tokens_query = OAuthClientToken - .where(oauth_client: @storage.oauth_client) - .where.not(id: @admin_tokens_query) - .includes(:user) + .where(oauth_client: @storage.oauth_client) + .where.not(id: @admin_tokens_query) + .includes(:user) # The user scope is required in all cases except one: # when the project is public and non member has at least one storage permission # then all non memebers should have access to the project folder if !(project.public? && Role.non_member.permissions.intersect?(PERMISSIONS_KEYS)) tokens_query = tokens_query.where(users: project.users) end - tokens_query.each_with_object({ - users: admins_project_folder_permissions, - groups: { "#{@group}": NO_PERMISSIONS } - }) do |token, permissions| - nextcloud_username = token.origin_user_id - permissions[:users][nextcloud_username.to_sym] = calculate_permissions(user: token.user, project:) - @nextcloud_usernames_used_in_openproject << nextcloud_username - end - end - def admins_project_folder_permissions - @admins_project_folder_permissions ||= - { - "#{@nextcloud_system_user}": ALL_PERMISSIONS - }.tap do |map| - @admin_nextcloud_usernames.each do |admin_nextcloud_username| - map[admin_nextcloud_username.to_sym] = ALL_PERMISSIONS - end - end + tokens_query end def add_active_users_to_group diff --git a/modules/storages/spec/services/storages/group_folder_properties_sync_service_spec.rb b/modules/storages/spec/services/storages/group_folder_properties_sync_service_spec.rb index 259be9325b5b..18f4bbd81031 100644 --- a/modules/storages/spec/services/storages/group_folder_properties_sync_service_spec.rb +++ b/modules/storages/spec/services/storages/group_folder_properties_sync_service_spec.rb @@ -231,6 +231,12 @@