Replies: 44 comments
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
-
@Marthisdil the For everyone else, 😢 please read this issue, there are some major problems with the ArchiveBox security model around how we deal with executing JS in archived content without allowing it to XSS the entire archive. This is a pretty major blocker as I'm not comfortable pushing a new version until it's "secure by default" and doesn't risk exposing people's feeds. I will try to put some time in, but this month and next are going to be very busy for me so PRs helping with the JS security would be very appreciated! For more details on the security and JS issues, see this PR comment: #207 (comment) This architectural problem happened because I originally designed ArchiveBox to only archive public feeds and publicly accessible pages, where leaking the list of pages in the archive was not a concern. When more people started using it for private content, it made sense to support that use case out-of-the-box. But now I need to go back and re-assess the assumptions that were made by the original design, and do it properly. I'll have to sacrifice some of the nice UX of having easily accessible archived files on disk, but unfortunately after talking about it with a few security people over the last weak, it's clear that there cannot be any insecurity by default, even if it does make the UX easier, and we must correct flawed design assumptions ASAP. I'll try and provide config options for people to get the old behavior back, but at this stage it looks like static archives will no longer allow executing JS anymore, breaking any interactive pages and forcing people to use a dedicated WARC replayer if they need that ability. PDFs, Screenshots, and all the other methods will remain unaffected, these changes will only disable JS for the primary wget static html archive. |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment has been hidden.
This comment has been hidden.
-
Hey all, v0.4 is officially released, check it out: We've closed over 30 tickets in this sprint, and made a bunch of major improvements to the CLI experience, data integrity, and web UI! pip install archivebox
cd path/to/your/archive/folder
archivebox init # doubles as the upgrade command, non-destructive & safe to run multiple times
archviebox add 'https://example.com'
archviebox add 'https://getpocket.com/users/USERNAME/feed/all' --depth=1
archivebox status
# archivebox config --set PUBLIC_INDEX=True (False=require a login to view the index)
# archivebox config --set PUBLIC_SNAPSHOTS=True (False=require a login to view individual snapshots)
archivebox server 0.0.0.0:8000
archivebox help docker run -v $PWD:/data nikisweeting/archivebox init
docker run -v $PWD:/data nikisweeting/archivebox add 'https://example.com'
docker run -v $PWD:/data -it nikisweeting/archivebox manage createsuperuser
docker run -v $PWD:/data -p 8000:8000 nikisweeting/archivebox |
Beta Was this translation helpful? Give feedback.
-
I forgot to post here when we released
|
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
-
FYI: #1082 Attention: I'm considering removing the |
Beta Was this translation helpful? Give feedback.
-
The plans for the next versions ahead can be seen here:
The Roadmap
Discuss your questions, comments, and concerns about large upcoming changes and high-level design direction in this thread.
Please DO NOT use this thread to discuss general bugs, small feature requests, or other things unrelated to long-term high-level roadmap direction or major architectural decisions.
(I will hide off-topic comments and direct you to open separate issues instead)
To see how the roadmap has been executed on so far, read these pull requests:
See all releases...
IMPORTANT: Please don't work on implementing any of the things in the roadmap without opening an issue to discuss it first, work is already in progress for big parts of these designs, and I may have to reject your PR if it doesn't align with the existing work!
Beta Was this translation helpful? Give feedback.
All reactions