1. 09 May, 2018 2 commits
    • Carlos Soriano Sánchez's avatar
      general: Don't allow launching binaries or programs in general · 3a22ed5b
      Carlos Soriano Sánchez authored
      For long we used to support that since the desktop was part of Nautilus.
      Also, back then we didn't have a Software app where you are expected to
      installs apps. Back then it was common for apps to be delivered in
      a tarball, nowadays that's out of question.
      
      Now that the desktop is long gone, launching binaries and desktop files
      from within Nautilus is not as useful. Not only that, but we are moving
      towards a more sandboxed system, and we should use the standard and
      system wide support for launching apps based on users choices.
      
      We also are not able to be secure enough to handle this, as we saw in
      the past we allowed untrusted binaries to be launched, and therefore
      we had a CVE (CVE-2017-14604) for Nautilus. We are not being audited
      (afaik) and we are not in a position that we can let this issues slip.
      
      With that altogether, this prevents launching binaries or programs from
      Nautilus.
      
      Closes: #184
      3a22ed5b
    • Carlos Soriano Sánchez's avatar
      83483358
  2. 23 Apr, 2018 3 commits
  3. 31 Mar, 2018 1 commit
  4. 01 Mar, 2018 1 commit
    • Ernestas Kulik's avatar
      general: don’t shadow variables · 6286e0a0
      Ernestas Kulik authored
      Shadowing variables is error-prone, since one might mean to refer to a
      variable that was declared earlier, but has the same name. Additionally,
      being more strict about variable scoping can help make the code more
      readable.
      6286e0a0
  5. 13 Feb, 2018 1 commit
  6. 21 Nov, 2017 2 commits
  7. 11 Aug, 2017 1 commit
  8. 09 Aug, 2017 1 commit
    • Carlos Soriano Sánchez's avatar
      general: Add mime type support for archives · 1bdc4042
      Carlos Soriano Sánchez authored
      Until now archives were managed only if activated from Nautilus itself
      and if a setting was set.
      
      There are two main problems with this.
      1- Archives opened in other apps cannot be handled by Nautilus
      2- Users cannot use the regular mime type handling for setting Nautilus
      as the app handling archives, or unsetting it.
      
      This patch add support for archives mime types handled by gnome-autoar
      and removes the UI and setting used in the previous version.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=771424
      1bdc4042
  9. 13 May, 2017 2 commits
  10. 06 Feb, 2017 1 commit
    • Carlos Soriano Sánchez's avatar
      mime-actions: use file metadata for trusting desktop files · 1630f534
      Carlos Soriano Sánchez authored
      Currently we only trust desktop files that have the executable bit
      set, and don't replace the displayed icon or the displayed name until
      it's trusted, which prevents for running random programs by a malicious
      desktop file.
      
      However, the executable permission is preserved if the desktop file
      comes from a compressed file.
      
      To prevent this, add a metadata::trusted metadata to the file once the
      user acknowledges the file as trusted. This adds metadata to the file,
      which cannot be added unless it has access to the computer.
      
      Also remove the SHEBANG "trusted" content we were putting inside the
      desktop file, since that doesn't add more security since it can come
      with the file itself.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=777991
      1630f534
  11. 30 Nov, 2016 1 commit
  12. 22 Nov, 2016 1 commit
  13. 21 Nov, 2016 2 commits
    • Carlos Soriano Sánchez's avatar
    • Carlos Soriano Sánchez's avatar
      mime-actions: support admin backend · 5db7a295
      Carlos Soriano Sánchez authored
      Until now Nautilus was not able to handle files where the user had
      no permissions. An error was reported.
      The only way for a user to handle those files were to start Nautilus
      with sudo, which is something that shoudl be avoided for security
      reasons.
      
      On Wayland, is not even possible to launch an application with sudo,
      so this is no longer available and therefor no way to handle files
      with no permissions.
      
      On 3.22 gvfs added an admin backend with integration with Polkit,
      so a file withouth permissions can be accessed using this backend
      if the user has the root password.
      
      Add support for the admin backend in Nautilus, where a file will
      be opened using it if cannot be read.
      
      There still work to do, basically implement the operations with
      this backend too and refactor the code to be able to open from
      nautilus application command line also a file withouth permissions.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=773937
      5db7a295
  14. 12 Nov, 2016 1 commit
  15. 02 Sep, 2016 1 commit
    • Alexandru Pandelea's avatar
      mime-actions: Fix shift+control+down seg fault on a folder · 5815ba1c
      Alexandru Pandelea authored
      Using this shortcut on one or more folders causes segmentation fault.
      
      In order to solve this, if there is a directory that needs to be
      activated, the NEW_WINDOW flag is set, so that the initial window will
      be closed and a new one will be created. After a new window is created,
      the CLOSE_BEHIND flag is disabled,so that the window will not be closed.
      The flags NEW_TAB is also set there(unless we want all directories
      opened in new windows), in order for new tabs to open in the newly
      created window.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=755711
      5815ba1c
  16. 29 Aug, 2016 1 commit
  17. 22 Aug, 2016 1 commit
  18. 04 May, 2016 1 commit
  19. 26 Apr, 2016 1 commit
  20. 25 Apr, 2016 1 commit
    • Carlos Soriano Sánchez's avatar
      general: merge libnautilus-private to src · 7e24f1b2
      Carlos Soriano Sánchez authored
      And fix make distcheck.
      
      Although libnautilus-private seem self contained, it was actually
      depending on the files on src/ for dnd.
      Not only that, but files in libnautilus-private also were depending on
      dnd files, which you can guess it's wrong.
      
      Before the desktop split, this was working because the files were
      distributed, but now was a problem since we reestructured the code, and
      now nautilus being a library make distcheck stop working.
      
      First solution was try to fix this inter dependency of files, but at
      some point I realized that there was no real point on splitting some of
      those files, because for example, is perfectly fine for dnd to need to
      access the window functions, and it's perfectly fine for the widgets
      in the private library to need to access to all dnd functions.
      
      So seems to me the private library of nautilus is somehow an artificial
      split, which provides more problems than solutions.
      
      We needed libnautilus-private to have a private library that we could
      isolate from extensions, but I don't think it worth given the problems
      it provides, and also, this not so good logical split.
      Right now, since with the desktop split we created a libnautilus to be
      used by the desktop part of nautilus, extensions have access to all
      the API of nautilus. We will think in future how this can be handled if
      we want.
      
      So for now, merge the libnautilus-private into src, and let's rethink
      a better logic to split the code and the private parts of nautilus than
      what we had.
      
      Thanks a lot to Rafael Fonseca for helping in get this done.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=765543
      7e24f1b2
  21. 14 Apr, 2016 3 commits
  22. 04 Apr, 2016 1 commit
    • Carlos Soriano Sánchez's avatar
      general: remove vim modelines · 1ffb8ca5
      Carlos Soriano Sánchez authored
      Vim and emacs modelines are used to specify some of the code style in the code.
      However, this is misleading and poorly supported since nautilus had a mix of
      code style for some time.
      Also, the mode lines doesn't specify the whole code style, so we will need to
      use a different tool as well to specify the whole code style.
      For that, we can just use a different tool for everything.
      
      So remove the mode lines, and in a short future we will reestyle the nautilus
      code to have a single code style, and use a tool like editorconfig to specify
      the whole code style.
      1ffb8ca5
  23. 29 Mar, 2016 1 commit
    • Razvan Chitu's avatar
      do not switch focus to new tabs · 9028e332
      Razvan Chitu authored
      In Nautilus, when a location is opened in a new tab, the new tab gets
      automatically focused. This behavior is not consistent with other tab-based
      applications, such as browsers - Epiphany, Firefox, Chromium to name a few. It
      is also a regression, since this behavior was not present in 3.14. In order to
      fix this, set a flag so the new tab is not made active.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=764035
      9028e332
  24. 07 Feb, 2016 1 commit
  25. 03 Feb, 2016 1 commit
  26. 11 Dec, 2015 1 commit
  27. 02 Dec, 2015 1 commit
    • Carlos Soriano Sánchez's avatar
      directory: assume recent as local · bfd0b4bf
      Carlos Soriano Sánchez authored
      We were assuming trash and native_path as local, but not recent,
      which is wrong.
      So assume recent as local, with the benefit that we can use it
      for mime type polling and remove some dead code now.
      bfd0b4bf
  28. 16 Nov, 2015 4 commits
  29. 28 Aug, 2015 1 commit
    • Carlos Soriano Sánchez's avatar
      general: separate handling of windows/slots/views · 28f50cfe
      Carlos Soriano Sánchez authored
      This is another step towards the isolation of the management
      of the direcotories, views, slots and windows.
      The current situation had a few issues:
      - the comunication of changes in the model was done in a
      bidirectional way. So for example, sometimes the view updates
      directly the slot, sometimes directly the window, and sometimes
      the window was listening to changes on the model and updating the slot,
      view, or model itself. Problem with this is, encapsulation is wrong,
      the code paths are confusing, and the public API exposed is big.
      - public API is big, so even if sometimes if convenient to not do the
      same thing twice, having public API that is actually covered by the GLib
      or Gtk API doesn't worth it, if the complexity of the API grows too much.
      In Nautilus case, specifically on the slot, we were allowing all kind of
      convenient API, but it was behaving differently depending on small connotations.
      - management was not encapsulated. So the window was modifyng the model, or
      doing actions that belongs to the slot or the view. The same thing for the slot
      and the view, and similarly for the application and the window. For example,
      we were handling the flag for creating new windows on a specific window,
      instead of relying on the application management. Similar cases for the slot
      and the view.
      - there were multiple code paths for opening a location. This is one of the
      biggest changes on the patch. We were exposing API to open a location in every
      component, and we were using that API from other components above or below the
      hierarchy randomly. So for example the view was using the opening location
      API from the slot, the window, and the application; but with the same pourpose,
      opening a location in the active window.
      - API was not explicit. For example sometimes we wanted to open
      a location in the current active window, but somtimes it was implicit and
      sometimes not, and to be safe we were making it explicit on the caller.
      - we were using mutiple code paths with the same intention. This is related
      to the previous one, the intention in every caller was not clear.
      
      This patch tries to improve the situation, also thinking on the future
      rework of the views and separation of the desktop handling.
      The patch applies the following rules:
      - If the API is provided somehow by nautilus-file or Glib or Gtk, don't
      add new API. Custom API is fine if it is used inside the component itself,
      since the added complexity for tracking code paths is not that important.
      - Use one way communication, from the top level to the innermost component.
      In case that the component needs top level features, ask the most top level.
      A specific example, the view provides opening a new window with a selection.
      Although encapsulation is good, there is not a good way to avoid the dance
      from the model to the view to the slot to the window to the application.
      So instead of that, allow a quick shorcut only communicating to the top most
      level. In this way, the code path is always the same (therefore much easier to
      debug or to change code) and encapsulation is preserved.
      - don't break encapsulation. Only allow management of the component to the component
      itself or its parent. So for example, the slot is the one that manages errors on what
      happens in the slot itself.
      Exception to this is the application, that needs access to all the hierarchy for
      specific situations. For example for updating the dbus locations or to discern
      between a desktop window or a common window.
      - if two way communication is needed, listen changes through properties.
      We have been moving to properties lately, since it clearer and cleaner and
      allow a few features that are useful like listening to its changes withouth
      explicit API for it. This allows to bind properties in a clean way throuh the
      hierarchy and not breaking the encapsulation.
      
      In this patch most of the ground work is done, and some things are remaining
      like moving all the loading of the location to the view instead of the slot.
      Even if it is convenient to have some management on the slot to share between
      the views, some views don't use models at all, or they are not common
      files, like the other-locations, and this breaks the situation. At some point
      what we want for the files-view is having a common model API, that can be on top
      of nautilus-file or in nautilus-file itself.
      
      With this patch, a serie of improvements can be done now, and they will
      come in future patches.
      28f50cfe