V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  codehz  ›  全部回复第 10 页 / 共 133 页
回复总数  2660
1 ... 6  7  8  9  10  11  12  13  14  15 ... 133  
这不都是你自己管理的东西吗,csp 防止的是未授权的修改,不是防止你在你自己域名上的授权修改
230 天前
回复了 pcdd 创建的主题 Windows Win 11 Bug 开始菜单突然打不开,怎么办
@Autonomous 替换了也没法解密用系统加密 api 加密的那部分,比如浏览器的 cookie ,保存的密码这些()这些只有用户正常登录了才可以被解密
@iOCZS 你这个理解上有一些问题,首先不管 class 组件还是 function 组件,都需要重复执行 render ,react 的核心算法就是根据生成的 vdom 去 diff ,这个是无法避免的。
只不过,传统 class 组件有提供简便的(但实际上很容易误用的)方法去直接跳过更新,这个能力在函数组件里是否存在呢,也是有的,就是那个 memo 函数,当然由于 hook 的存在,不能像函数组件那样屏蔽来自 hook 的更新,但这也导致写出有问题的代码更为困难了
确实是不再推荐了,因为和并行渲染这些新的机制有冲突
@StruggleYang 经过测试,14.4.1 已经修复了这个错误,不是给 java 开后门,整个错误都修了
241 天前
回复了 Noicdi 创建的主题 C++ C++单例模式构造时的多线程安全问题的相关请教
实践中,编译器会给你生成一个 double checking lock
啥,4k 你用 100%来看,和 1080p 用 100%不是一样的效果的吗。。。
nomodule 的兼容性是指:支持 nomodule 的浏览器就不去加载这个 script
不支持 nomodule 的就会自动加载(因为不认识的 attribute 被忽略)
要讨论这个问题,得先设定一个威胁模型吧,不如就来一个直接拉满的模型:
攻击者方面
1. 攻击者完全了解该协议。
2. 攻击者可以访问大量常用密码字典(并且有足够多的时间离线破解)。
3. 攻击者可以窃听客户端和服务器之间的所有通信。
4. 攻击者可以拦截、修改和伪造客户端和服务器之间的任意消息。
5. 没有相互信任的第三方。
最后攻击者的目标是冒充客户认证,这里不考虑“在线”暴力破解的情况,也不考虑注册过程中客户被冒充的情形。

这个模型下,所有基于固定密码的 web 认证方案都是无效的,因为攻击者只需要伪造登录页面就可以直接偷到正确密码。( WebAuthn 是终极解决方案)
那我们可以弱化其中一个攻击条件,假设 webapp 已经事先作为 pwa 部署到用户设备上了,因此攻击者无法篡改登录页面(*),这种情况下,可以继续讨论前端加密的意义。

1. 首先排除单纯的摘要算法,因为只要把摘要本身认定为登录密码即可冒充用户
2. 我们可以考虑单纯的预先共享密钥的方案,也就是对称加密,这条基本上也可以 pass ,因为攻击者也能拿到预共享密钥(什么,你说一次一密?那攻击者伪造一个假的给客户端不就可以了)
3. 至于非对称加密的方案,尽管这次攻击者拿不到服务端私钥,没办法直接偷到密码,但是由于第二条,攻击者可以离线破解密码
。。。剩下的方案,基本也就是排列组合,在上面那个威胁模型下能起到的作用顶多是减缓攻击者的破解速度

那有没有完美的算法解决这个问题呢?答案是有的,只要从一开始,就不发送任何关于密码的信息给服务器即可
通过零知识证明,客户端和服务端分别向对方证明自己拥有密码,但服务端却无需得到密码的原文(或者任何衍生信息)
将零知识证明用到认证领域的协议就是(非对称的) PAKE ,一个常见的具体协议是 OPAQUE 协议。协议内容在这里不细说,可以在 https://blog.cloudflare.com/opaque-oblivious-passwords 里看到细节,但在理论上它是能抵御前面所提到的所有威胁的。
246 天前
回复了 YugenFring 创建的主题 程序员 kotlin 可以完美平替 Java 吗?
不是完美平替,企业的例子我不知道,mc 模组里,fabric 的模组,无法在 mixin 中使用 kotlin (原因是 kotlin 的标准库会有冲突)
@houshuu 但其实没什么用,这次的问题是随机概率触发的,上面有人就没触发过。。。
合理的方案是在不破坏互操作性的前提下(例如不能出现旧版本无法打开项目的情况),进行灰度升级
全屏实现其实挺复杂的(因为跳过了窗口混合的过程),对老游戏可能可以 dxhook 一下,但虚拟机的估计没那么好做。。
除非 vmware 用的是无缝窗口模式,那种也许可以骗过去。。。
@daveh
这个修改也只是另一个性能优化 https://bugs.openjdk.org/browse/JDK-8283326

SafeFetch is important - mostly when writing hs-err reports, but it is also used in low level utility functions like `os::print_hex_dump()` and `os::is_readable_pointer()`. It is also used (JDK-8282306) as part of call stack printing. At the moment it is implemented via dynamically generated stub routines
@daveh 没错是改成 static 了,但还是用信号的啊 https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/safefetch_static_posix.cpp
只不过把 safefetch 本身的代码用汇编写成直接一个 mov 或者 ldr
https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/bsd_aarch64/safefetch_bsd_aarch64.S
不是很懂为啥要杠这一点
@daveh https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/safefetch_sigjmp.cpp 在 posix 下的实现就是 sigsetjmp 保存跳转地址,然后在异常处理代码里检测 SIGSEGV 和 SIGBUS 来跳转到返回 false 的分支
@daveh SafeFetch 整个函数的意义就是访问非法地址的时候能检测到结果,你是不明白这个 fetch 的含义吗。。。
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/safefetch.hpp#L31-L32
@lslqtz 你看的是 https://developer.apple.com/documentation/xcode/investigating-memory-access-crashes 这个吧,问题是这并不是同一个问题,它是“调查因内存问题而崩溃的方法”
@daveh 我不知道你是在哪里得来的这个结论
https://bugs.java.com/bugdatabase/view_bug?bug_id=8320317
是这个吗?确实删除了一个对 SafeFetch 的调用,可问题是是在这里吗,后文不也提及了
JDK-8320317 removes this specific call to SafeFetch. We could probably still still hit similar issues with other calls to SafeFetch
@daveh 此外 pthread_jit_write_protect_np 是只有 macOS 给 apple sillicon 提供的功能,solaris 根本就没这个 api ,何来的十几年的垃圾代码
@daveh 这个问题就是苹果的错误,就算 JRE 触发是一个意外,也不能改变它就是苹果的错误,因为这个行为( pthread_jit_write_protect_np 0 的时候 SIGSEGV 和 SIGBUS 变为 SIGKILL )没有任何文档提及,也没在更新日志里包含,乃至专门介绍安全性的更新内容( https://support.apple.com/zh-cn/HT214084 )的文档也没有说有这个变更
OpenJRE 自己去 workaround 这个问题,和苹果意外搞出的错误没有任何关系
1 ... 6  7  8  9  10  11  12  13  14  15 ... 133  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1551 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 29ms · UTC 17:02 · PVG 01:02 · LAX 09:02 · JFK 12:02
Developed with CodeLauncher
♥ Do have faith in what you're doing.