Path contained within .blend is may be too verbose #45546
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
9 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#45546
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
System Information
Linux (Intel graphics)
The nature of the bug is independent of the issue reporting.
Blender Version
Tested on 2.75
Exact steps for others to reproduce the error
Implications
The implication of this issue is that this may pose privacy concerns in some cases when .blend file is distributed.
Perhaps, it is not so much of concerns in general usage, but could be an issue if the particular .blend file is output from production machines in a company, which can leak sensitive project names and other information.
Suggestion
Perhaps there is usefulness in retaining histories within the .blend file, however, it might be great to have an setting that inhibits inclusion of private information, as well as an option on the save dialog to strip such information.
Changed status to: 'Open'
Added subscriber: @HidekiSaito
#102161 was marked as duplicate of this issue
Please note, I did not do a comprehensive analysis of strings in the file. (There are a lot of strings included in a file.) But I felt this one's least expected.
Added subscriber: @ideasman42
Changed status from 'Open' to: 'Archived'
The Blend file writes Blender structures as they're stored in memory,
So even if this one issue were resolved - there are many places where setting a relative path for example - will leave part of the absolute path after the trailing null terminator - for example.
If this were as simple as changing file writing in a few places, it may be worth resolving.
But I'm afraid this kind of file-format hygiene just isn't supported, and would require much bigger changes to file writing code.
Currently we don't consider it a bug.
Added subscriber: @fablefox
"Currently we don't consider it a bug."
While I agree with that, I think the point raised by the OP "but could be an issue if the particular .blend file is output from production machines in a company, which can leak sensitive project names and other information." could be a mission critical in getting Blender used by studios.
In a matter of fact, this is where Ton and several others sit down, talk clearly, and release another minor version of current release.
It may not be a bug, but if obviously a flawed design (IMHO) and is a very critical thing.
Added subscriber: @Ton
If people or companies are concerned, it will be quite simple to make a .blend anonimizer.
We can mark it as a todo item, and wait for the first case of someone who needs it. A big studio I mean.
And to be honest, I have to see the first big studio that shares their files on public forums.
"And to be honest, I have to see the first big studio that shares their files on public forums."
Hi Ton, it doesn't have to be public forum, but between contractors / vendors.
Imagine Studio A might hire VFX House Z to do a scene. But VFX House Z might also do special effect for Studio B.
You (Studio A) may doesn't want VFX House Z to share with Studio B what movies you have in the pipeline. Getting movies out earlier is enough to steal profit / thunder.
Anyway, thanks for the reply.
Added subscriber: @brecht
In my experience with production files from big VFX studios, such absolute paths revealing names of projects or characters are everywhere and no one is protecting against that. In fact relative paths seem to be quite rare and a lot of VFX software isn't capable of handling relative paths as well as Blender does.
What studios will often do is use code names or acronyms for the project directory, I don't know if that's a protection strategy or just because the name hasn't been decided yet or it's too long to type.
Added subscriber: @jta
Added subscriber: @KevinMossey
So, I only use Blender for a hobby, as I'm an engineer by trade - but I wanted to say that any serious engineering firm that is going to share any kind of technical document(s) with anyone else, will have that person or organization sign an NDA (Non-disclosure agreement) before handing anything over. At that point, it doesn't matter if you know anything of the internal path names, etc. If that firm leaks any of that information, they are now liable.
I would imagine any large studios would work the same way - if they have something secret they need to share, wouldn't they force everyone involved to sign NDAs? I mean, I had to sign one just to interview at my current job, then I had to sign another one when I got the offer.
I would consider this a non-issue.
Added subscribers: @WCN, @ThomasDinges