• SqlPackage or DacFx Version: SSDT 16.0.62205.05200
• .NET Framework (Windows-only) or .NET Core: 4.8 / 3.1
• Environment (local platform and source/target platforms):
  • Windows 10
  • VS 2019 16.11.26

If one has an interesting folder structure with strange or fancy folder names - everyone who gets dacpac from this person will get this information thus will be able to use it, possibly against the person who produced a dacpac.
Of course, this does not look like a terrible vulnerability, but for sure this is not comfortable when you know it and is absolutely unexpected.

This behavior is reproduced in CI builds inside temp build folders which will no longer exist after the build is finished. Which makes me believe that these paths embedded into dacpac metadata are of no use.

IMO dacfx should put into the built dacpac the same (relative or whatever) path to dacpac-dependency from sqlproj as is. Otherwise this information should be removed from built dacpac to avoid described information exposure.

Steps to Reproduce:

1. Create a folder structure like c:/test/I like Janet/And hate Mike/dacpacs and c:/test/I like Janet/And hate Mike/new db
2. Put existing dacpacs into /dacpacs to use them as dependencies for new db project
3. Make a new sqlproj in /new db folder
4. Add dacpac dependencies into new db.sqlproj using relative paths to dacpacs in the ../dacpacs folder
5. Build this new db.sqlproj
6. Go into built dacpac internals, view model.xml
7. See absolute paths to dacpacs telling the story about your relationships with Mike and Janet to everyone
8. Realize that there is no place in the sources where you mentioned absolute paths describing your local workplace environment

Relative paths in the project

Become absolute paths in the dacpac after building the project

Did this occur in prior versions? If not - which version(s) did it work in?
no such version

(DacFx/SqlPackage/SSMS/Azure Data Studio)