-
Notifications
You must be signed in to change notification settings - Fork 413
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
Javadoc exposes absolute paths in dokka-configuration.json #3958
Comments
Hi, thanks for the report. I agree that the For some context: I recently changed the
The When I run the library-publishing-example, it doesn't include the dokka/examples/gradle-v2/library-publishing-example/build.gradle.kts Lines 12 to 16 in fc574c8
However, I think it's too easy to make a mistake. I'll see if I can find a better way to prevent the config file from being accidentally shared as an output. |
Ah, I see, auto-output usage mine indeed! It is coming from here: Since the param is defined as Object at I guess I could do the selection myself as well, but you're right that it's easy to make this mistake if we use implicit outputs. |
Dumping the Dokka config files is useful for debugging, but can interfere with task outputs. Here we add a flag that disables the dumping the config file by default, but we enable it for our own tests. Fix #3958
Dumping the Dokka config files is useful for debugging, but can interfere with task outputs. Here we add a flag that disables the dumping the config file by default, but we enable it for our own tests. Fix #3958
Describe the bug
Just migrated to Dokka 2.0.0, and I was diffing the artifacts of publishToMavenLocal. I found that the new javadoc jar contains the absolute paths of the source files and classpaths.
This means the resulting artifacts are not reproducible.
There might be also a security risk as some companies use Dokka to generate javadoc for public APIs and publish them online. These could leak internal implementation details of their systems, and the paths could be used to learn about their build machines. This could in theory aid attackers to exploit vulnerabilities more easily.
Expected behaviour
Relative paths or paths with env vars or no paths at all?
(Note re relative paths: my Gradle and Project paths are on separate Windows drive letters, so there's no way to navigate between them with
../
. Even if that was possible the depth of the folders would still make it not reproducible.)Screenshots
I replaced my local absolute paths with
GRADLE_USER_HOME
andPROJECT_CHECKOUT_DIR
.To Reproduce
gradlew dokkaGeneratePublicationJavadoc
and inspect the javadoc jar.Dokka configuration
Workaround
(For this users have to notice that this is happening so that they can action it.)
See https://github.com/Kotlin/dokka/blob/v2.0.0/dokka-runners/dokka-gradle-plugin/src/main/kotlin/tasks/DokkaGenerateTask.kt#L99-L106
Attempt 1
Follow docs...
Tried also wrapping in
afterEvaluate
, neither worked.Attempt 2
Delete file at the "right" time.
but this is way too hacky.
Attempt 3
Hail Mary... based on some random intuition.
Bingo!
Installation
The text was updated successfully, but these errors were encountered: